This is a tricky thing. If you are officially acknowledged as a representative of your company or the Khronos OpenGL ARB WG more people want to be involved in what you say and how you say it.
Keeping the forums informal is the best way to keep information flowing and to get an idea of what individuals really think. In the end, I’d rather hear from the individual than get the party line from Khronos or a member company.
To that end, I would hope that Khronos, AMD, NVIDIA, Apple, etc would encourage open discussions. They don’t commit anybody to any course, but they would allow developers to follow the logic of the current directions and to be more involved in the process by way of voicing concerns or making suggestions.
We still need regular official information dumps though - via newsletters and (even more desirable) meeting minutes that don’t have all the interesting bits redacted.
That’s my wish, too. And I’m aware of the implications of this suggestion. But the point is, that I really want to speak to officials. It’s fine to have informal discussions and I don’t see why officials wouldn’t be allowed to state their personal opinions.
To be honest, I’m currently checking if staying with OpenGL is a wise descision. From a technical point of view there’s little concern. Despite some minor issues, GL3 looks good to me. It has introduced a feature that can bring a new level of “vitality” to the API: the deprecation model. But this feature heavily relies on discussion. See above, Rob and Michael are asking for feedback. That’s good, but it looks like their efforts are based on personal commitment. Bringing the conversation to a more official level would possibly force some other ARB members to openly express their intentions. Which then would lead to some open discussion. Maybe. Wishful thinking?
Could having multiple FBOs could possibly provide a performance advantage if the FBO objects were left static after creation? Presumably the driver could have a compiled copy of the command buffer commands required to setup the FBO render state for future draw calls (effectively the point of immutable objects). Should also reduce the amount of error checking. Also if the hardware has multiple sets of hardware frame buffer states, using multiple FBOs might allow the driver to better match logical FBOs to those hardware states?
If you really want to be heard you are encouraged to join Khronos - even at the non-voting level you may participate in the debate and may influence the outcome. We really could use more ISV participation - there are a few now but increasing that number would increase the likelihood of a “representative sample”.
As for tagging myself as an ARB representative - I think it would discourage me from posting, as I’m not authorized to speak on behalf of the group. Most people here know who I am, and I try to make clear from context when I am stating ARB policy and when I am stating personal opinion. I walk a fine line.
In theory, keeping the FBO static can help. Unfortunately textures are mutable, so the implementation may need to check if any attached objects are dirty even if the container (FBO) itself is not. Worse, the spec is unclear when a change to e.g. a texture format becomes visible to a consumer of this object (think shared objects and async changes in another thread). This is why I continue to push for immutability - it eliminates this entire class of problems.
All else being equal, you’re still better off leaving the FBO state static after setup.
Since quite a few ARB members (e.g Rob, Michael or Cass) are reading and asking for input, why not centralizing this? Having a thread where both ARB people can ask questions (such as do you really want to have wide lines in GL3.x?), as well as developers (Gimme multi sampled textures already)
This thread would be updated maybe once a month or so by ARB members posting what the general impression of the ARB was with respect to feature this or rant that.
This way, it is not really formal such as meeting notes or newsletters, but would still allow some information flow in both directions.
However it would be important that this thread gets updated regularly and maintained properly, e.g. by creating a new one every month/quarter/whenever something happened.
Currently, people are asking questions and get answers spread all over the place.
A good start would be the list of possibly deprecated list of features gone in the next revision (Rob mentioned something like that in another thread). So posting this list, even if it is just for discussion, without any guarantees whatsoever would feel the pack at ease and give the ARB some input.
Having a thread where both ARB people can ask questions (such as do you really want to have wide lines in GL3.x?), as well as developers (Gimme multi sampled textures already)
The thing is, we have an entire forum dedicated to the possibility of that. If the ARB wanted to solicit advice from users, they could just create a thread in the “Suggestions for the next release of OpenGL” forum, and we’ll respond.
We don’t need a special thread for it. Besides, having everything in one thread is confusing.
Michael, it’s somewhat confusing me, that ARB members don’t want to appear as ARB members in their own forum. I can’t suppress the feeling, that you’re still far from consensus. Well, I’d better shut up, because obviously I don’t have a clue what’s going on behind the scenes.
Whats wrong with what I suggested earlier,
once a month someone on the ARB eg Rob Barris, Michael Gold or whoever starts a topic here titled ‘October 2008’ and just summarizes whats happened over the last month.
Ok I can see arguments against this as its not the ARB sanctioned gospel, but perhaps the post can start with a disclaimer stating this.
To ARB members, the prospect of ongoing obligations in community service is probably not an appealing one. That’s just more work for them in the spotlight of public scrutiny (put yourself in their shoes). Leaving things on an opt-in basis seems fair to me.
I’d sure like to see the newsletter press reopened.
So as for GL 3.1 what can we expect? My predictions (/wild speculation),
(1.) Some time 2009, perhaps late Q1?
(2.) Working NVidia, and ATI GL3 drivers. Apple perhaps with Snow Leopard in January (10.6 going to have OpenCL right?). Intel perhaps not because of Larrabee not being out yet.
(3.) Geometry shaders, texture buffer objects, and instancing extensions get rolled into the core spec.
(4.) Uniform (parameter) buffer objects as an extension. Question as to if this functionality gets supported on older hardware which need to patch shaders after uniform changes.
(5.) Unlikely, but perhaps something to do with texture fetch from multisample textures. Maybe only a vendor extension.
Other things I would personally like to see in GL.
(1.) Roll in fence support (NV_fence/APPLE_fence) into the core spec.
(2.) Support for fences to be shared across contexts!
(3.) Would be nice to have support for keeping a buffer mapped with MapBufferRange( … MAP_UNSYNCHRONIZED_BIT … ) mapped during drawing. So one could keep filling in dynamic VBO ring buffers from other threads easily.
(4.) Would be nice to have support for MapBufferRange( … MAP_UNSYNCHRONIZED_BIT + MAP READ BIT … ) with the same functionality of being mapped during drawing. Combined this in the form of a readback ring buffer, with shared context fences and transform feedback, then GPU readback could become a lot more useful.
The “mapped during drawing” thing is not very likely to happen. MapBufferRange was designed to work in at least two different ways in the underlying implementation for certain kinds of traffic.
So the first way is, the memory the CPU sees while mapped is memory that can be simultaneously observed by the GPU (i.e. GART/AGP mapped or PCIe DMA wired). And in a world like that, you might be able to make draw-while mapped work - as long as the draw call knows to flush CPU write caches so the shared RAM has the right bits in it.
But the second way, specifically in cases where the app has requested write-only with range or buffer invalidation, allows the driver to provide a piece of scratch memory that may have no residence in the actual buffer, as a destination for the writes.
The magic happens at FlushMappedBufferRange or unmap time - as long as the written bytes are transferred into the GPU visible buffer before the draw gets underway, all is well. This was set up in this fashion to accommodate systems where establishing DMA mappings fluidly to arbitrary pieces of system memory is cumbersome - it also allows for idioms where you are mapping tiny pieces of a huge buffer, the tiny pieces can be doled out from a ring buffer of scratch space and re-used over time with a fixed DMA mapping.
But in the second world, you have to have that flush or unmap event happen so the signal of when to transfer the newly written bytes is received by the driver. I suppose this raises the question of “well, would flushing of a range be sufficient on its own, without the actual unmap - turn unmap into a no-op”? - that one I don’t have an immediate answer for.
I’m thinking about the proposal of “flush as good as unmap”. We’ve already gone past my comfort zone (that happened when we introduced the unsynchronized bit - you can blame/thank Rob for pushing hard for this feature), so its possible that we’re no worse off with this proposal. The problem is historically developers don’t get this kind of thing right, or they think they do and it breaks on a new driver or chip, forcing us to add heuristics to try to fix the broken app without slowing everyone else down. (In an ideal world the developer would just fix the app so the driver doesn’t have to - but the PC space is less than ideal. In this day and age, if you ship a title without a self-patching mechanism, shame on you!)
The other problem with allowing an app to hold a mapping indefinitely is that it messes with memory management. We cannot relocate a buffer which is mapped.
And this (using flush) is exactly what I had in mind. Map buffer. one thread draws using ring buffer, other thread(s) can write and flush into that buffer without the need to be concerned with needing an unmap at any point where the primary thread is issuing draw calls. Of course the mapped buffer would also have to be shared across contexts.
One thing we would possibly get with this functionality is easier porting of stuff we do on consoles to the PC/Mac.
It would certainly complicate memory management. I’d guess (with no knowledge of the XP or Vista driver model), that the user side mapping shouldn’t be a tremendous problem in itself, assuming the driver can change the page table physical mapping (for a fixed user space address) when it needs to move stuff around (say when user changes primary display resolution). In the worst case, ie the driver is out of usable memory (which should never happen, but needs to not crash in case of), perhaps the driver could map all the previously mapped user space pages to a single common junk physical page and then return error later on a modified version of FlushMappedBufferRange().
While I agree with the decision to deprecate almost everything on the list in Appendix E, there were a few items whose removal didn’t make sense to me: quads, alpha test, and the luminance / luminance-alpha / intensity internal formats. I’ll try to explain why it’s good to have each of these around.
Quads. I use these a lot for particle systems, fire, and other special effects where you end up rendering a bunch of disjoint quads that have their vertex positions recalculated every frame. It just makes sense to dump the four corners of each quad into a buffer and let the hardware render them as quads. Quads are supported in hardware by all Nvidia chips and all recent ATI chips. If quads go away, then I have to either (a) dump six vertices into the vertex buffer for each quad instead of four, or (b) construct an index buffer in addition to the vertex buffer that wasn’t necessary before. In both cases, we lose speed and increase memory requirements.
Alpha test. This one isn’t a huge deal, but why should we have to add a texkill instruction to our fragment programs when all hardware already supports a separate alpha test that doesn’t eat up an extra cycle in the fragment processor? Taking away alpha test just slows alpha-tested rendering down a little bit without simplifying the driver in any significant way.
L / LA / I internal formats. I have found these formats to be very convenient, and I know that they are supported in all modern hardware through a programmable swizzle/crossbar in the texture units. Consider the following scenario: you’re using a fragment shader that reads an RGB color from a texture map. Now you want to change the texture map (perhaps in the middle of a game) while using the same exact shader, but the new texture map is grayscale, so you decided to store it in a single-channel format to save space. If you load it into GL as a luminance texture, then the shader continues to work correctly without modification because the texture unit distributes the single channel to all three RGB channels for free. If you take away the luminance-based formats, then you’re forced to build a completely different shader for the single-channel case. This creates an extra hassle for the software developer without really simplifying the driver at all. (Setting the texture units swizzle register is dirt simple.)
I noticed that all three of these items represent features that are not supported in DirectX 10. Were they deprecated just to achieve some kind of feature parity between the two libraries?
In order to do this reliably, moving the data and remapping the PTEs need to happen atomically. I don’t see a way to do this for arbitrarily large buffers.
If quads go away, then I have to either (a) dump six vertices into the vertex buffer for each quad instead of four, or (b) construct an index buffer in addition to the vertex buffer that wasn’t necessary before. In both cases, we lose speed and increase memory requirements.
Unless the hardware can’t actually support it anymore and thus emulates it.
I noticed that all three of these items represent features that are not supported in DirectX 10. Were they deprecated just to achieve some kind of feature parity between the two libraries?
Not so much feature parity but driver parity. Each step away from the low-level is another step away from making drivers easy to write.
Though I wish you could have gotten them to approve the Fences necessary to guarantee safety…