This is a feedback thread, and I provide feedback. If you don’t even disagree with it, please keep the noise down. We’re all disillusioned with the ARB, but keeping quiet isn’t going to solve anything.
They’re already maintaining two specs anyway.
At some point this nonsense should just stop. Introducing a complete DSA API is the perfect opportunity to realize what was originally planned 4 years ago.
Hey, speak for yourself! 
I second the rest of what you said, but let’s avoid the grandstanding too. Each of us represents our own suggestions and opinions – no others.
Over the years, I’ve come to appreciate the difficult job the ARB has. They’re never going to please anyone completely (and they’re limited by corporate budgets and priorities), so if anyone out there’s holding their breath for complete nirvana, they might as well sit down before they pass out. Just throw your opinion out there for consideration, and don’t get your panties all in a wad if you don’t get everything you want. You’re not the only fish in the pool.
Sorry, I meant to point out that Reinheart isn’t the only one disillusioned, not grandstand. Back to the topic of feedback, I forgot to mention the elephant in the room: Can we please have multi-threading in OpenGL?
Can we please have multi-threading in OpenGL?
A GPU is inherently multi-threaded - following AMD rhetoric it’s even ultra-threaded. The problem is the single command buffer you can fill. Multi-threaded OpenGL can be done using two or more contexts in different threads. However, if you have a single command buffer and you switch threads it’s nothing more than adding GL commands sequentially to that command buffer depending on what thread is currently pushing. If you have multiple command buffers, as with multiple GPUs, you can have true multi-threading.
Can we please have multi-threading in OpenGL?
You can - just create a separate GL context for each thread, belonging to the same share group. You can then have some threads create objects, fill buffers, etc. while another does the rendering. This is precisely what GL_ARB_sync is for.
I don’t understand why everybody is asking for multi-threading in OpenGL since D3D has it. FYI: OpenGL always had multi-threading support.
D3D’s multi-threading approach is not much different. Only deferred contexts are something that OpenGL doesn’t have, though it’s kind of similar to display lists. Also, deferred context promise more than what they actually achieve as in practice they barely give any benefit.
Neither of those cases are very interesting, since the most common hardware setup is multiple CPU cores and a single GPU. Direct3D solves this by having multiple command lists for a single GPU. Isn’t that feasible for OpenGL as well?
It doesn’t matter if it’s similar, because OpenGL doesn’t have display lists.
Direct3D solves this by having multiple command lists for a single GPU.
And does the hardware actually map that to multiple parallel command streams as well? Multiple streams in software don’t give you much gain if you are still forced to be sequential in hardware.
A D3D deferred context is almost exactly as described - record API calls on a separate thread then play them back on the main thread. There’s a very obvious case it targets and that’s the case where the cost of making these API calls sequentially on the main thread outweighs the overhead of threading and of making two passes over each command (once to record and once to play back). It shouldn’t be viewed as a “implement this and you’ll be teh awesome” feature, rather, it needs careful profiling of your program and informed decision making. Implement it in a program that doesn’t have the performance characteristics it targets and things will get worse.
Correct, and in order to decide whether to use a feature or not it needs to exist.
Will GL_EXT_depth_bounds_test be promoted to core now that both AMD and NVidia support it?
The OpenGL 4.3 core spec removed the GL_ALPHA format for glReadPixels (chapter 18.2.1, page 458). The other single-component formats GL_RED, GL_GREEN and GL_BLUE are supported, but GL_ALPHA is only supported in the compatibility profile. In 4.2 core all 4 individual components could be read with glReadPixels.
Is there a reason why the alpha channel is treated special here ?
It also needs to be used by a lot of people. If very few people actually use a feature, then it usually has very little testing or IHV support. Anything “not on the common paths” is very likely to blow up or not provide any benefits, just due to the exponential branching complexity of oh-so-many features. Ideally, any proposed feature would have some kind of “preliminary consensus” that it can indeed be a benefit, and would indeed match a lot of people’s expected case uses.
The nonsensical description of DrawElements was eventually fixed in 4.3 spec, nice! However, it would be good if the
description of the “indices” parameters would reflect the according meaning on the ref pages as well (of it being an offset,
not any sort of pointer C-type).
This is mostly incorrect. Features are (or should be) tested before they are released regardless of popularity of each feature, and the way to achieve that is to write tests or use an existing test suite which can assess the quality of an OpenGL implementation. There is the official OpenGL conformance test suite developed by Khronos that driver developers should use first. There is also Piglit, the unofficial open source OpenGL test suite, which is pretty huge and it’s getting bigger every day with 89 contributors so far. Finally, driver developers should write their own tests for features they implement (I know major vendors do that, though the specification coverage of their tests might vary a lot, considering AMD passed about 75 % of Piglit tests last time I checked, which is not very good, and NVIDIA even less than that).
This is mostly incorrect. Features are (or should be) tested before they are released regardless of popularity of each feature, and the way to achieve that is to write tests or use an existing test suite which can assess the quality of an OpenGL implementation.
You seem very conflicted about what you’re saying.
On the one hand, you’re saying that the post is wrong to say that only some features are being tested. Yet you cite low Piglit scores and the obvious lack of comprehensive testing by driver developers. So clearly some features are not being properly tested. So you agree with Brandon’s point: that staying on commonly tread ground is the most effective way to avoid driver bugs.
The post you’re responding to is not talking about what “should be”; the post is talking about what is currently. And you seem to agree with his explanation of the current state of things.
So what is “mostly incorrect” about what he’s saying?
There is the official OpenGL conformance test suite developed by Khronos that driver developers should use first.
If there is a desktop OpenGL conformance test, I haven’t heard of it. The old conformance test for desktop GL was never updated; it never even checked conformance to 2.0. So it’s worthless for anything more recent. OpenGL ES 2.0 and 3.0 have conformance tests, but not desktop GL.
Khronos said that they were interested in making one, but they haven’t announced anything beyond interest.