Khronos Public Bugzilla
Bug 695 - ARB_vertex_attrib_binding inconsistency
Summary: ARB_vertex_attrib_binding inconsistency
Alias: None
Product: OpenGL
Classification: Unclassified
Component: API Specification (show other bugs)
Version: 4.2
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Jon Leech
QA Contact:
Depends on:
Reported: 2012-08-15 02:19 PDT by Alfonse
Modified: 2015-10-22 14:16 PDT (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alfonse 2012-08-15 02:19:50 PDT
Pursuant to the resolution of bug 693:

> I believe all those functions are listed in the "Dependencies on EXT_direct_state_access" section at the bottom.

Function prototypes should always be listed in the `New Procedures and Functions`. Certain spec parsing systems that pull data from the specification files (rather than the .spec files) will assume that functions are defined in the `New Procedures and Functions`.

Every other extension that has similar dependencies lists all the function prototypes there. And some specialized parsing tools work directly from the `New Procedures and Functions` section, and will therefore be broken by this change.

So at least for consistency's sake, this should be changed in the extension specification.
Comment 1 Jon Leech 2013-07-11 01:31:03 PDT
I have asked if we can move the DSA-style entry points out of ARB extensions
and into the EXT_dsa spec itself, which would in part address this. It
is also consistent with NVIDIA's take on these functions as belonging to
DSA. If there's agreement there will be a flock of spec updates to shuffle
DSA language out of ARB extensions and into DSA. It will probably take a
while for this to bubble to the top of the agenda.
Comment 2 Mark Kilgard 2015-10-22 14:16:18 PDT
We discussed this bug at the October 2015 f2f (Houston).

Discussion items:

1)  GLEW only returns true for an extension being supported if EVERY listed entry point is supported.  This is definitely incorrect for EXT_direct_state_access where entry points advertised depends on the set of other extensions advertised.  In other words, selector-free API is added by EXTdsa if the corresponding extension functionality is exposed.

2)  The XML file maintained by Jon Leech @ Khronos doesn't have an attribute for functions saying what other extensions the function depends on being supported, but the consensus was that would be a good thing to have.

3)  I took the action item of contacting the GLEW maintainer (Nigel) and seeing if we could have GLEW at some point support the XML file to improve this.