KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
678 stars 274 forks source link

[XML] Performance query group and class definitions #576

Closed SunSerega closed 1 year ago

pdaniell-nv commented 1 year ago

@Perksey any objections to this change from you?

NogginBops commented 1 year ago

It might be good to do something like we did with kinds where we keep a list of the ones that are present in the specification. Otherwise I have no problem with this.

SunSerega commented 1 year ago

Do you mean something like this? (I thought spec is the .pdf file)

<classes>
    <class name="..." description="...">
</classes>

When I was suggesting this for kinds (you quoted it here), I noted the difference with classes:

Unlike classes, which are solely defined by their uses and being a namespace, [...]

So the human-readable description would probably be redundant for classes... But maybe some other info, like the extension, in which the class is defined, would be useful... What do you think could be better described in this way?

NogginBops commented 1 year ago

I guess I mostly wanted some way to know about what a "perf query" is as it's an extension concept and not part of the core OpenGL specification. But maybe gl.xml isn't the right place for that.

pdaniell-nv commented 1 year ago

This is approved to merge if @NogginBops doesn't object.

SunSerega commented 1 year ago

I guess I mostly wanted some way to know about what a "perf query" is

Yeah, that's understandable... But I think starting from that is backward. For the use cases I see - I expect people to first understand a function, which uses a class. Then, while looking at another function - notice the handle of the same class is needed, so they must be connected. And that alone would already give the consumer all the info there is about the said class.

Perksey commented 1 year ago

I think a schema change is out of scope of this PR specifically.

NogginBops commented 1 year ago

Sorry for responding so late! I'm absolutely fine with merging this PR.

pdaniell-nv commented 1 year ago

@oddhack this is approved to merge.