Khronos public bugtracker – Bug 703
DSA functions from other specs.
Last modified: 2013-07-17 15:49:11 PDT
A number of recent OpenGL extensions have had alternate versions of functions to fit with the EXT_direct_state_access specification. ARB_texture_storage, ARB_vertex_attrib_binding, and ARB_clear_buffer_object, just to name a few.
However, this introduces a concept that is not reflected in the .spec files: a function that requires *multiple* extensions in order for it to be present. There is no setting in the entry for, for example, TextureStorage2DEXT that says that this function in any way relies upon the presence of EXT_direct_state_access.
This means that, for example, "glcorearb.h" contains a function pointer definition for glTextureStorage2DEXT, even though it's only supposed to contain definitions for *core* OpenGL functions. And glTextureStorage2DEXT is not a core OpenGL function; it is not found in the OpenGL 4.2 or 4.3 specifications.
It also means that a naive OpenGL loader will attempt to load function pointers for these entrypoints based on the presence of the ARB extension, not EXT_direct_state_access. And certainly not based on the union of these two.
The .spec files need to be updated to contain some information about this sort of thing.
So my first thought on this in the XML context is to add an 'extension='
attribute to <require> tags. If the targeted extension isn't part of
the interface being generated, then that block isn't included in the
interface either. This doesn't accomodate the case where >2 features
have interdependencies at the interface level, but that may be vanishingly
I still don't have a great answer for this. However, Mark Kilgard recently
sent me some updates for DSA which make it clear that in their internal
.spec files, they consider all DSA functions to belong to the EXT_dsa
extension. I have modified gl.xml accordingly, moving the DSA EXT
entry points introduced by ARB extensions into the EXT_dsa extensions
block. This hasn't been reflected in the actual extension specs yet,
which continue to describe the functionality as part of the ARB
extension but requiring DSA, though I've asked the ARB if we can move
the relevant language into EXT_dsa proper.
I'm attaching a file glext_dsa.spec that includes all of NVIDIA's DSA entry points.
You'll notice there's a "subcategory" field that associates commands with the extension they provide a selector free API for.
Jon, I hope you can use this subcategory .spec entry to populate your <require> XML attribute.
If you can do that, can we close out this bug? Let me know if you need further information and I'll be glad to help.
Some replies to Jon's comments...
> they consider all DSA functions to belong
We do clump entry points together in our spec file but that's just for simplicity and because we started that way.
But in new extension specifications, we've found dependencies on EXT_direct_state_access are best documented in that new extension. This matches the long-established principle that newer extensions state dependencies on pre-existing extensions. Anything else is difficult to work out because:
* extensions are developed independently,
* developers naturally want to find selector-free APIs documented with the new API,
* it's error prone (we've seen this in practice) to try to keep the DSA spec synchronized with the new extension,
* NVIDIA has worked to add DSA interactions to specifications as we specify or implement newer specifications; this allows the DSA interactions to be coordinated with the extension developer.
> I've asked the ARB if we can move the relevant language into EXT_dsa proper.
I think the much better solution is to incorporate the existing proven DSA mechanisms into core GL standards. While vendors may argue about this, ISVs are simply using the proven DSA interfaces in their code.
In larger part this problem is created by the lack of standardization of DSA interfaces.
It creates a lot of frustration for developers when the ARB chooses some functions to provide selector free interfaces (e.g. glProgramUniform* in OpenGL 4.1, etc. but not others).