Key Advances in the OpenGL Ecosystem
khronos.org
khronos.org
Right now there's a variety versions of OpenGL out there and they are incompatible in subtle ways. To write "portable" graphics code, you need both compile time and runtime version checks for a variety of features. Some restrictions in mobile versions make sense because of hardware requirements, others are just plain ridiculous.
And the versions of OpenGL that vendors ship is very diverse. For years, Nvidia and AMD have been the only ones to provide (at least almost) the latest version of OpenGL (but only on Windows and Linux, not Mac). Other vendors are lagging behind by several years.
I won't even start listing the obvious problems with the OpenGL API. Everyone who is working with it knows that the API is ridiculous.
I'd like to see an API clean up (ie. rewrite from scratch), a common shader compiler frontend, a common shader binary format and common tooling like benchmarking and profiling tools. Perhaps even a software emulated "gold standard" implementation.
At the moment, writing practical OpenGL applications is miserable. It's quite alright as long as you're working on a small project for your own enjoyment but once you have to start dealing with a variety of driver bugs from different vendors and whatnot, it takes a lot of time to actually ship an application.
And might I add: A debugger! For both shaders and the entire GL state. Yes, 3rd party tools exist. But more often than not, I find they won't even compile or execute on a given platform.
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.
- 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.
Yes it is and most language bindings are generated using them. This also includes "OpenGL extension loaders" which are required in C apps too.
Examples illustrating what I am saying:
http://stackoverflow.com/q/6530700
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 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.
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...
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.
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);
setColor(RED);
movePen(100, 100);
lineTo(200, 250);
lineTo(300, 300);
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.
This initiative is about one major thing: reducing overhead. It's a response to Mantle/DX12 and their low CPU overhead rendering capabilities. OpenGL risks being left behind performance-wise because drivers are too complex. Because the API hasn't evolved as fast as the capabilities of modern hardware changed, drivers today do too much automatic work "behind the scenes". Things like memory allocation, texture swizzling, parameter validation, and shader recompilation often happen implicitly, outside of the control of the application. This adds unexpected CPU overhead which varies per driver.
Mantle/DX12 change the semantics of the API to match what modern hardware actually does. Applications have more control, drivers do much less implicit automatic work and CPU overhead is greatly reduced. That's what the "Next Generation OpenGL Initiative" is hopefully going to do for OpenGL.
It's competition, but for a much much smaller piece of open gl's pie.
OpenGL code will run on billions of mobile devices, but metal will only run on iOS which is an ever-shrinking share of total smartphone sales each year.
Anyone who picks metal over opengl is picking iOS only--period. Any crossplatform game that doesn't want to write the entire game multiple times (once for apple, once for crossplatform, or heck onece for every platform) will simply not pick metal or any OS-dependent API.
The competition is going to exist in middleware. Unreal, Unity, etc, will have Metal-optimized implementations on iOS, because they're still a big market.
The real threat to OpenGL is if the Metal implementation on these engines is so substantially more powerful than the OpenGL implementation, and results in better-looking games or games running on cheaper/slower hardware.
AAA studios do it all the time.
http://www.polygon.com/2014/6/2/5773128/metal-ios-gaming-wwd...
Whose job it would be then?
There is AMD's Mantle and Apple's Metal as well as Google's somewhat related RenderScript. As long as they're going to remain a single vendor API, they will be adapted as an universal new API.
But hopefully the work by these vendors (all of which are Khronos members) will serve as a basis for a future standard API.
Longs peak was a failure and the API was very complicated. It was definitely a failure due to design by commitee.
But in the end, there has to be an industry consortium to standardize on a new API. When we're talking about an API that is closely tied to the hardware it runs on (which is a lot more expensive to develop than APIs and software), there's no other option than to get all the big players around the same table. Right now, Khronos is the most likely candidate since all the key players are members in that group.
At some point there has to be a new API. OpenGL isn't just an API with some warts in it, it's getting more and more in the way of new development.
If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?
I think the only realistic way forward without breaking backwards compatibility is to build a new low overhead close to the metal API and implement OpenGL on top of that (e.g. adding a new MESA backend). Doing a new API on top of OpenGL first is quite impossible.
But I wouldn't mind breaking backwards compatibility either. I think D3D does the right thing here and every major version is incompatible with the previous version. Porting to the next version isn't too difficult (mostly a search and replace job) but it's still not source or binary compatible. I think this is the major reason why D3D is a cleaner API.
> If driver overhead is minimized, so that OpenGL is as thin a layer as possible over the real hardware, then changing the API becomes trivial: you can just wrap OpenGL and expose any API you want on top.
Given the convoluted mess that OpenGL drivers are (I work on one), it is very unlikely that such things will happen. We can't reduce driver overhead by adding new stuff. Some parts we can help (see the "Approaching Zero Driver Overhead" talks) but there's still an inherent overhead from all the state validation and other complexities.
Also, wrapping OpenGL into anything nicer isn't really possible. Otherwise there would be lots of neat 3D APIs implemented on top of OpenGL and you could choose whichever you like. But it's impossible to work around the idiosyncrasies of OpenGL.
And writing wrappers is fundamentally incompatible with low overhead anyway.
> Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL
That "someone" would need to be a major established player and the API must be something that actually catches on. It must be complete and functional.
Khronos isn't just going to fork a random dude's GitHub project and go from there. There are practical reasons but let's not forget the legal issues either.
This scenario isn't just gonna happen.
This is a great idea and it should happen, but a Khronos committee is not the right place to do it. The only way it could end well is if the API is first designed and implemented outside of Khronos and Khronos's only role is to standardize it with minimal changes. For example, if Khronos decides to adopt Mantle as the basis for this new API, with a few changes to make it generalize better to all vendors' hardware, then that would be a good outcome. I fear that politics may not allow something like that to happen, and that's why I think a more incremental approach is better, but perhaps I'm too pessimistic.
I'm afraid that Khronos is the only entity that can possibly do something like this. However, as you suggest it might be possible that the basis of a new API is one of the new proprietary APIs like Mantle or Metal.
You seem to have some kind of dislike for Khronos but I don't think there is any better entity out there. The problem with Khronos is that it's understaffed and underfunded and for many of the people doing the hard work it's their secondary job.
The lack of up-to-date OpenGL versions on MacOS-X is not the fault of NVidia, AMD or any other GPU vendor. It's entirely Apple's fault. Apple insists on developing the MacOS-X OpenGL drivers themselves. And because OpenGL has been rooted so deep in the MacOS-X graphics stack it's virtually impossible to update without upgrading the rest of the operating system as well. Well done Apple, well done…
Even just having the common binary format there would be a huge step forward. It'd let the community take care of the rest if khronos doesn't bother with it. The software emulated standard implementation would be really nice. things like mesa's piglit would be great for using it as a test suite.
I used to be a big OpenGL fan, back in the GL 2.x / DX 8 days.
However the way OpenGL grew up is just insane, specially for the poor beginners that didn't grew up with the API.
Not to mention the basic stuff (texture loading, fonts, math, shader usage) that the API leaves out, whereas other 3D APIs offer some kind of support.
Plus the consoles never had proper support anyway.
To the point that nowadays I advise anyone just to use a rendering engine.
Leave programming OpenGL directly to learn how to build an engine.
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
Mantle caused MS to rapidly announce DX12. So it's the exact same direction where everyone else is going.
While DX is more pleasurable to use than OpenGL (I personally am purely OpenGL dev, yet I acknowledge it's weaknesses) it has similar limitations. Very limited threading model and massive CPU overhead in drawcalls.
The future of graphics api's is going to be mantle style command buffer generation from multiple threads and then sending those buffers to the GPU.