6 ms·

Key Advances in the OpenGL Ecosystem

115 points by Jarlakxen 12y ago

theandrewbailey 12y ago
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.
exDM69 12y ago
OpenGL is long overdue for a spring cleaning. A bit less than 10 years ago there was an initiative to create a new OpenGL API, code name "Longs Peak" which would have solved some of the obvious issues there are. 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.
- jarrett 12y ago
  > 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.
- rrradical 12y ago
  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.
  - flohofwoe 12y ago
    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.
    - fzltrp 12y ago
      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.
- modeless 12y ago
  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.
  - baq 12y ago
    agreed; simply reminding that apple's metal is very likely also a factor.
    - criley2 12y ago
      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.
      - potatolicious 12y ago
        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.
- datenwolf 12y ago
  > 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…
- simcop2387 12y ago
  > 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.
- pjmlp 12y ago
  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.
SynchrotronZ 12y ago
The quotes on that page feature the best job title I have ever seen: "Aras Pranckevičius, graphics plumber at Unity."
- robterrell 12y ago
  BTW Aras is a great guy to follow on twitter: https://twitter.com/aras_p https://twitter.com/aras_p
  - Kronopath 12y ago
    Heh. https://twitter.com/aras_p/status/496027538460651521 https://twitter.com/aras_p/status/496027538460651521
bitwize 12y ago
Next Generation OpenGL: Key Advances That Will Bring OpenGL to Where Direct3D Was Two Years Ago.
- sharpneli 12y 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.
DonHopkins 12y ago
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/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
- flohofwoe 12y ago
  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.
NINJATESTER 12y ago
HOLA FACU:D!

115 points by Jarlakxen 12y ago

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.

exDM69 12y ago

OpenGL is long overdue for a spring cleaning. A bit less than 10 years ago there was an initiative to create a new OpenGL API, code name "Longs Peak" which would have solved some of the obvious issues there are. 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.

jarrett 12y ago
> 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.
rrradical 12y ago
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.
- flohofwoe 12y ago
  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.
  - fzltrp 12y ago
    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.
modeless 12y ago
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.
- baq 12y ago
  agreed; simply reminding that apple's metal is very likely also a factor.
  - criley2 12y ago
    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.
    - potatolicious 12y ago
      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.
datenwolf 12y ago
> 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…
simcop2387 12y ago
> 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.
pjmlp 12y ago
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.

SynchrotronZ 12y ago

The quotes on that page feature the best job title I have ever seen: "Aras Pranckevičius, graphics plumber at Unity."

robterrell 12y ago
BTW Aras is a great guy to follow on twitter: https://twitter.com/aras_p https://twitter.com/aras_p
- Kronopath 12y ago
  Heh. https://twitter.com/aras_p/status/496027538460651521 https://twitter.com/aras_p/status/496027538460651521

bitwize 12y ago

Next Generation OpenGL: Key Advances That Will Bring OpenGL to Where Direct3D Was Two Years Ago.

sharpneli 12y 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.

DonHopkins 12y ago

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/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

flohofwoe 12y ago
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.

NINJATESTER 12y ago

HOLA FACU:D!