3 ms·

So is there a reason graphics programming is still in the dark ages. This sounds like assembly programming where you have N different add instructions with slig

So is there a reason graphics programming is still in the dark ages. This sounds like assembly programming where you have N different add instructions with slightly different semantics for how flags are set.

kcbanner 13y ago
The thing is, there are people that require that level of control to achieve the performance they want.
Hemospectrum 13y ago
The primary reason is that these APIs are very thin abstractions over the actual assembly-level instructions sent to the graphics card. It's certainly possible to write a higher-level abstraction; it's been done many times, in the form of game engines and so forth. The risk of doing so is that you narrow down the possible types of visual effects you can implement, and historically, the implementation of unique and original visual effects was a big part of the way AAA games competed with each other. In principle there's no longer any reason why it has to work this way, because now we have shaders. These are a more domain-specific tool than a C API, and can thus safely present large cross-sections of graphics card functionality in a higher-level way without taking power away from the graphics programmer. So, for example, people modding Minecraft can introduce their own visual effects stages by hotloading shaders into the standard Minecraft graphics pipeline. EDIT: I haven't talked about performance. For game developers, rendering a frame quickly is as important as having total control over the output of the rendering process. For the most part, building an API higher-level than OpenGL also means dictating a particular scene graph structure, as with OS-specific window system APIs. If the API imposes a certain way of organizing your scene graph, this can have serious impacts on your game's performance, because the scene graph traversal is optimized for one type of scene and you're using it for another. I'm not sure I'm simplifying this explanation very well, but that's the gist of it.
- yoklov 13y ago
  I don't disagree with what you're trying to say, but this is my line of work so I have a few nits, sorry. > these APIs are very thin abstractions over the actual assembly-level instructions sent to the graphics card If only this were the case... The drivers end up doing quite a bit, to the point where most renderers spend most of their time waiting for the driver to return. This is part of the reason Mantle was a big deal, and why DX12 and GL5 promise to be lower level. > In principle there's no longer any reason why it has to work this way, because now we have shaders Shaders don't replace all the fixed function parts of the GPU, and they don't try to. Maybe someday they'll replace more of it, but there are still several fixed function stages in the rendering pipeline. Not to mention, setting GPU state will pretty much always be completely independent from shaders, and required for many visual effects. D3D or CG FX files try to abstract this, but I don't think they're popular anymore. > For the most part, building an API higher-level than OpenGL also means dictating a particular scene graph structure... The general premise that any layer on top of the driver will limit on the way you structure the renderer is accurate, but scene graphs are an antipattern inside a modern renderer. Plenty of engines use them for higher level organization, but keep it far away from the renderer. All that pointer chasing murders the cache.
kllrnohj 13y ago
Well the author also contradicts themselves. For example, this complaint: > Drivers should not crash the GPU or CPU, or lock up when called in undefined ways via the API runs directly counter to this complaint: > They will not bother to re-write their entire rendering pipeline to use super-aggressive batching, etc. like the GL community has been recently recommending to get perf up. Error checking = higher per call overhead = slower performance. If you think there should be a way to turn on a sort of safe-mode or something where the driver holds your hand that sounds reasonable, except for this: > I've seen major shipped GL apps with per-frame GL errors. (Is this normal? Does the developer even know?) In other words, the error checking the driver does to is largely ignored. Adding additional error checking at the cost of performance? That won't help at all.
- corillian 13y ago
  He's referring to the difference between the D3D debug layer (http://blogs.msdn.com/b/chuckw/archive/2012/11/30/direct3d-sdk-debug-layer-tricks.aspx http://blogs.msdn.com/b/chuckw/archive/2012/11/30/direct3d-s...), which can be toggled on/off for debug/release builds (or even forced on in the driver), and OpenGL's near worthless glGetError() and debug output callback. Not only does D3D come with better debugging capabilities built directly into the API/driver its tools are vastly superior to OpenGL's - though with Valve's VOGL and NVIDIA's nSight that's beginning to change.
deleted 13y ago
[deleted]
flohofwoe 13y ago
And an "assembly-level graphics API" is exactly what is needed at the moment. The high-level abstractions are taken care of by game engines like Unity or UE, or programming frameworks for a specific scenario (e.g. 2D UI rendering vs. 2.5D side-scroller games vs. AAA first-person-shooters). One problem with GL (also D3D) is that it provides fairly highlevel abstractions which don't exist on the hardware level and either limit the flexibility or performance (e.g. OpenGL has "texture objects", when the GPU actually just sees a couple of sampler attributes and a blob of memory). Mantle provides exactly that simplified view on the GPU, and as a result is a much smaller API (but may be harder to code to).

kcbanner 13y ago

The thing is, there are people that require that level of control to achieve the performance they want.

Hemospectrum 13y ago

The primary reason is that these APIs are very thin abstractions over the actual assembly-level instructions sent to the graphics card. It's certainly possible to write a higher-level abstraction; it's been done many times, in the form of game engines and so forth. The risk of doing so is that you narrow down the possible types of visual effects you can implement, and historically, the implementation of unique and original visual effects was a big part of the way AAA games competed with each other. In principle there's no longer any reason why it has to work this way, because now we have shaders. These are a more domain-specific tool than a C API, and can thus safely present large cross-sections of graphics card functionality in a higher-level way without taking power away from the graphics programmer. So, for example, people modding Minecraft can introduce their own visual effects stages by hotloading shaders into the standard Minecraft graphics pipeline. EDIT: I haven't talked about performance. For game developers, rendering a frame quickly is as important as having total control over the output of the rendering process. For the most part, building an API higher-level than OpenGL also means dictating a particular scene graph structure, as with OS-specific window system APIs. If the API imposes a certain way of organizing your scene graph, this can have serious impacts on your game's performance, because the scene graph traversal is optimized for one type of scene and you're using it for another. I'm not sure I'm simplifying this explanation very well, but that's the gist of it.

yoklov 13y ago
I don't disagree with what you're trying to say, but this is my line of work so I have a few nits, sorry. > these APIs are very thin abstractions over the actual assembly-level instructions sent to the graphics card If only this were the case... The drivers end up doing quite a bit, to the point where most renderers spend most of their time waiting for the driver to return. This is part of the reason Mantle was a big deal, and why DX12 and GL5 promise to be lower level. > In principle there's no longer any reason why it has to work this way, because now we have shaders Shaders don't replace all the fixed function parts of the GPU, and they don't try to. Maybe someday they'll replace more of it, but there are still several fixed function stages in the rendering pipeline. Not to mention, setting GPU state will pretty much always be completely independent from shaders, and required for many visual effects. D3D or CG FX files try to abstract this, but I don't think they're popular anymore. > For the most part, building an API higher-level than OpenGL also means dictating a particular scene graph structure... The general premise that any layer on top of the driver will limit on the way you structure the renderer is accurate, but scene graphs are an antipattern inside a modern renderer. Plenty of engines use them for higher level organization, but keep it far away from the renderer. All that pointer chasing murders the cache.

kllrnohj 13y ago

Well the author also contradicts themselves. For example, this complaint: > Drivers should not crash the GPU or CPU, or lock up when called in undefined ways via the API runs directly counter to this complaint: > They will not bother to re-write their entire rendering pipeline to use super-aggressive batching, etc. like the GL community has been recently recommending to get perf up. Error checking = higher per call overhead = slower performance. If you think there should be a way to turn on a sort of safe-mode or something where the driver holds your hand that sounds reasonable, except for this: > I've seen major shipped GL apps with per-frame GL errors. (Is this normal? Does the developer even know?) In other words, the error checking the driver does to is largely ignored. Adding additional error checking at the cost of performance? That won't help at all.

corillian 13y ago
He's referring to the difference between the D3D debug layer (http://blogs.msdn.com/b/chuckw/archive/2012/11/30/direct3d-sdk-debug-layer-tricks.aspx http://blogs.msdn.com/b/chuckw/archive/2012/11/30/direct3d-s...), which can be toggled on/off for debug/release builds (or even forced on in the driver), and OpenGL's near worthless glGetError() and debug output callback. Not only does D3D come with better debugging capabilities built directly into the API/driver its tools are vastly superior to OpenGL's - though with Valve's VOGL and NVIDIA's nSight that's beginning to change.

deleted 13y ago

[deleted]

flohofwoe 13y ago

And an "assembly-level graphics API" is exactly what is needed at the moment. The high-level abstractions are taken care of by game engines like Unity or UE, or programming frameworks for a specific scenario (e.g. 2D UI rendering vs. 2.5D side-scroller games vs. AAA first-person-shooters). One problem with GL (also D3D) is that it provides fairly highlevel abstractions which don't exist on the hardware level and either limit the flexibility or performance (e.g. OpenGL has "texture objects", when the GPU actually just sees a couple of sampler attributes and a blob of memory). Mantle provides exactly that simplified view on the GPU, and as a result is a much smaller API (but may be harder to code to).