Not sure if it’s unique to Linux.
I’m trying to replace a glElementsInstanced call with its indirect equivalent, with the command object being allocated on stack and passed through with a pointer. According to the khronos refpages, this should act just like glDrawElementsInstancedBaseVertexBaseInstance (which does work).
I’m on OpenSUSE Tumbleweed, driver nvidia-glG05 440.64-24.1, GTX 1650 Super
nvidia-bug-report.log (2.4 MB)
If you’re using a core profile context, you must have a buffer object bound to the GL_DRAW_INDIRECT_BUFFER slot, and the “indirect” parameter will be a byte-offset into that buffer. If you want to use application-managed memory to hold your indirect buffer, you’ll have to use a compatibility context.
If you’re already doing that, can you be a bit more specific about the workflow? Perhaps you can provide a partial code listing, or, ideally, a simple test program that demonstrates the issue.
1 Like
Oh, is the compatibility context profile required since 4.6?
This is really weird. I’m looking at the specs for the OpenGL 4.6 core and nowhere is there a mention that a DRAW_INDIRECT buffer is required for that particular function, nor are there any deprecation messages about sourcing commands from client memory.
Yes, the spec does seem a bit ambiguous here from my reading. What I reported was based on our driver behavior (based on inspection of the code), and (in my opinion) the intended interpretation of the ambiguous spec language.
Section 10.3.9 of the 4.6 spec notes that behavior is undefined if buffer object zero (I.e., what used to indicate client vertex arrays prior to their deprecation+removal in GL 3.1) is bound to an enabled array at draw call time. Section 10.3.11, which defines indirect buffers, defines them in terms of the behavior in section 10.3.9. However, it does not explicitly replicate the “undefined behavior” language for a zero buffer object like section 10.3.10 (index buffers) does, so on its own you could argue the intention was client memory be allowed here. The reason I believe this interpretation is invalid though is that if you compare the language in the same section to that in the 4.6 compatibility spec, you’ll see the compatibility spec explicitly includes additional language in section 10.3.11 to define behavior when buffer object zero is bound to the indirect buffer target. This to me implies the behavior is NOT defined, or in other words, undefined, when using the compatibility profile.
Still, I’ve filed a bug against the spec to clarify the point: Ambiguous requirement for non-zero indirect buffer object in core profile · Issue #65 · KhronosGroup/OpenGL-API · GitHub
1 Like
Oh, you’re right.
Seeing the description in section 10.4, it feels like this paragraph should be a part of the Core profile. Thanks for filing the issue, I’m looking forward to it being resolved.