4 ms·
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 v
by 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 agoHe'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.