Hacker News Reader

Comment by rrradical | Hacker News Reader

Would you mind clarifying your problems with the API? I've done a fair amount of work with OpenGL (mostly ES), and I've found it to be a sensible low-level target for my rendering engine. That's not to say I haven't run into problems, but I assume any high performance graphics API has a learning curve. I don't have experience with Direct3D or other APIs to compare with it though.

All of my complaints with OpenGL are related to, as jarrett mentioned, the lack of debugging tools and the fiddly cross-platform and cross-version issues.

View on HN

Without getting into details, the worst part of the API is the inherent statefulness of it. To exaggerate a little, OpenGL is essentially a very complicated global state variable where state changes have side effects. (actually it's thread local but global scope in most programming languages - but this only makes matters worse)

If you look back (or remember) graphics APIs from the 1980s and 1990s (e.g. the BGL library that shipped with Borland compilers), this was a common idiom.

Rather than saying

    drawLine(100, 100, 200, 250, RED);
    drawLine(200, 250, 300, 300, RED);

You did

    setColor(RED);
    movePen(100, 100);
    lineTo(200, 250);
    lineTo(300, 300);

The idea behind this was to minimize the number of parameters passed to function calls, because they had to be pushed to the stack and then read back. This was a major source of performance overhead back then.

So basically OpenGL is modelled after a performance optimization that was relevant some 30 years ago. These days it's actually hurting performance and adding unnecessary complexity. Premature optimization of the worst kind.

You could do a little comparison on how Direct3D 10.1 and newer work. The API is simpler, lot less stateful and you get a better idea what will actually happen. If I had a choice, I would use D3D, but it doesn't run on the platforms I care about.

The most confusing part to me is that the 'fast paths' in the API are not obvious, especially if you need to support older GL versions (GL2, GLES2). For instance:

- Using Vertex Array Objects should be fast since it's only a single call to change the vertex data binding. But in many GL implementations they are slower then using the old way calling VertexAttribPointer and EnableVertexAttribArray

- What's the fastest way to update dynamic vertex data? Buffer orphaning? Doing double buffering yourself? BufferData or BufferSubData? It's likely that the answer is different dependent on driver or GPU

Resource binding can introduce subtle errors by screwing up the GL state (for instance to create and initialize a resource you need to 'make it current', should the creation function restore the previous binding, or keep the GL state 'dirty'?)

Some call parameters are overloaded with completely different meaning depending on GL state. For instance the 'const void* pointer' argument in VertexAttribPointer is actually an integer offset and not a pointer if an array buffer is bound.

The most important problem which the OpenGL NG initiative tries to solve is validation overhead. In current OpenGL, an app can change every state at every time in the frame, and after each change (or rather before each draw call) the entire GL state must be validated. Most games (or 3D apps in general) only create a relatively small set of 'pre-compiled' state at startup and then just switch between these state presets. With this pattern, all expensive validation can happen once at startup, and not during the render loop.

In my humble opinion, they should write formal specifications which are not just targetting a C API, but may degrade consistently to a C API. With a more formal description of each function call, including predicates for parameters, and possibly the context itself, they make things way easier for user land, where these could be mechanically translated into API bindings, and thus checked automatically. If all these checks are made on the user side, then they may add a simple toggle in the API to remove the checks on the driver side. Most users aren't using the C API directly anyway, and people writing bindings would welcome specs which could be mechanically translated into their favorite language bindings. The problem might remain for WebGL though.

There's actually an XML spec, don't know whether this is enough to automatically generate language bindings from it though: https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/pub...

> don't know whether this is enough to automatically generate language bindings from it though

Yes it is and most language bindings are generated using them. This also includes "OpenGL extension loaders" which are required in C apps too.

I have to admit that, while I knew these documents existed, I was not aware they included as much information as they do: I was under the impression that it was merely an xml version of the original C headers to facilitate their parsing. Having a second look, it seems that it also covers information like array expected size and valid enum subsets for parameters, which is very valuable data for all players using the API (even driver implementors could use it to generate basic conformance tests).

The craziest thing I found in OpenGL API was that there was no way to bind data to a primitive. You have to repeat it for every vertex of the primitive, which sometimes also means that you can't share vertices between primitives. This results in a 9x overhead in data for triangles!

Examples illustrating what I am saying:

http://stackoverflow.com/q/6530700

http://stackoverflow.com/q/6056679

http://stackoverflow.com/q/23879737

You can definitely "bind data to primitives" and share vertices between triangles in OpenGL and that has always been possible ever since the first version of OpenGL.

Are you talking about legacy OpenGL style glBegin/glVertex/glEnd? That hasn't been the preferred way of drawing ever, and since OpenGL 1.5 (circa 1999), vertex buffers are the way to go.

If you want to share vertices between triangles, you should build and index buffer and use glDrawElements* functions.

I meant to say "bind data to elements". It's been a while since I programmed in OpenGL so the terminology is shaky.

I saw your other answer below too. I am not able to visualise how the duplicate data could affect caching postively. But anyway, I don't have deep knowledge about the hardware.

And I didn't know other 3D APIs had the same problem. Thanks for mentioning that.

You can share vertices between primitives if all vertex components are the same and indexing is used.

That's the same on all 3D APIs though. I think the only exception was the Wii where you could have positions, texcoords, normals, etc... in different arrays of different sizes and index them with multiple indices per vertex. I can't image that this was efficient though...

There are some cases where you can't share vertices. For example, flat shading with face normals. So now you need to put that normal data into every vertex and you have to duplicate vertices as well, which is 9x data for a very common use-case.

True, but I don't know any 3D API which allows this except for the OpenGL 1.x style glBegin/glEnd which doesn't map to an efficient hardware implementation. This specific problem can be solved by not fetching per-vertex normals at all, and compute the face normals on the fly in the geometry shader, not sure whether this is worth it though, geometry shaders have a reputation for being nearly useless.

> For example, flat shading with face normals

I see your point, having interlaced vs. non-interlaced data arrays. Many 3d model interchange formats use the latter because it saves some bytes. All 3D APIs use the former.

But this example works exactly the same way on every 3d API out there. Having a single index per vertex (rather than separate indices into position, normal, texcoord arrays) simplifies the vertex pipeline a little bit.

Using a single index will also make more efficient caching of vertex data and post-transform caching (ie. output of vertex shaders are cached if possible). Separate indices would need more complicated cache addressing.

Of course, with modern OpenGL, you can do more complicated addressing of data in the vertex shader. This isn't likely going to increase performance, though.

However, this is largely a non-issue. Modern 3d graphics simply isn't limited by the number of vertices or triangles. Having to duplicate some data isn't going to make a significant difference in practice.

Also, you can toggle the interpolation mode for varying variables (ie. fragment shader inputs) so you can use per-vertex normals and make them flat shaded if your whole model is going to be flat shaded.

Reply on news.ycombinator.com