Key Advances in the OpenGL Ecosystem(khronos.org)
khronos.org
Key Advances in the OpenGL Ecosystem
https://www.khronos.org/news/press/khronos-group-announces-key-advances-in-opengl-ecosystem
43 comments
The Next Generation OpenGL Initiative isn't about an API cleanup, rewrite, tooling, benchmarking, or profiling. Those are all areas that could use improvement, but a standards body is not the place to do those things. Trying to do those things in a standards body is a recipe for logjams and delayed and bloated standards. "Longs Peak" is a prime example actually.
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.
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.
> but a standards body is not the place to do those things.
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.
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.
Focusing on reducing driver overhead is the right way forward. 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. Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required.
I think your idea is completely crazy. Feel free to disagree.
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.
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.
>build a new low overhead close to the metal API and implement OpenGL on top of that
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.
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.
> This is a great idea and it should happen, but a Khronos committee is not the right place to do it
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.
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.
I hope that someone is either Facebook/Occulus or Google.
> Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required.
If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?
If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?
agreed; simply reminding that apple's metal is very likely also a factor.
The inefficiency of PC 3D APIs compared to game consoles is an ongoing discussion since at least 2007. So far all low-level APIs have been designed for one specific GPU, or at least a specific architecture (like Mantle on AMDs GCN). Apple's move was unexpected, but much easier then trying to implement a low-level API which runs equally well on a wide range of GPU architectures. DX12 and 'GLNG' will be the first to really tackle that. But I have faith since there's enough 'prior art' in the form of game console 3D APIs, Mantle and Metal.
Is metal that much of a factor to 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.
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 isn't going to happen at the end-developer level. Few game developers are actually going to be touching Metal directly.
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.
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.
Apple is encouraging Metal adoption through game engines like Unreal Engine 4, Frostbite and Unity (among others) to make it less demanding for developers.
http://www.polygon.com/2014/6/2/5773128/metal-ios-gaming-wwd...
http://www.polygon.com/2014/6/2/5773128/metal-ios-gaming-wwd...
Ever heard of rendering engines?
AAA studios do it all the time.
AAA studios do it all the time.
> 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)
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…
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…
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.
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.
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
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.
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.
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.
- 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.
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).
[deleted]
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
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.
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.
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...
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.
> 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.
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.
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.
> common tooling like benchmarking and profiling tools
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.
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.
> 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.
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.
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.
Many upvotes!
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.
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.
The quotes on that page feature the best job title I have ever seen: "Aras Pranckevičius, graphics plumber at Unity."
BTW Aras is a great guy to follow on twitter: https://twitter.com/aras_p
Direct State Access is finally in the core spec. That might be the last missing piece of what OpenGL 3.0 was supposed to be.
We've come a long way from the time that the HP technical support person asked Steve Strassmann "Why would you ever need to point to something that you've drawn in 3D?"
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
In a twisted way that's still true though :) Getting the content of the pixel beneath the mouse still isn't trivial since CPU and GPU run in parallel and the CPU is at least one frame ahead. In general it's better to only push data into the GPU, and not trying to read any data back with the CPU.
Next Generation OpenGL: Key Advances That Will Bring OpenGL to Where Direct3D Was Two Years Ago.
Not quite. It will be like Mantle.
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.
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.
HOLA FACU:D!
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.