Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added len and group attributes to wgl.xml #569

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

NogginBops
Copy link
Contributor

This PR aims to add some of the metadata present in gl.xml into wgl.xml.

One problem I've found is that if needing to reference enums or enum groups from gl.xml, and I do think the namespaces should be kept separate. Maybe the GL enum values could be added under some tag in the xml? Or prefix the tags with something like GL::TextureTarget for example. None of the solutions stand out as the "correct" one.

@NogginBops
Copy link
Contributor Author

@SunSerega @Perksey might be interested to comment on this PR.

@SunSerega
Copy link
Contributor

SunSerega commented Mar 24, 2023

ColorBuffer and PixelType are already found in gl.xml and have different purposes from groups of the same name you added.

@NogginBops
Copy link
Contributor Author

NogginBops commented Mar 24, 2023

ColorBuffer and PixelType are already found in gl.xml and have different purposes from groups of the same name you added.

Yeah, when making this PR I was envisioning GL, WGL and GLX as different enum group namespaces. I personally think that they should be considered different namespaces for groups, but there could be arguments for making them the same namespace.

This is not a C problem as these groups are not used in the C headers, so that is at least one things that we don't have to worry about.

xml/wgl.xml Outdated Show resolved Hide resolved
@@ -72,44 +72,44 @@ Registry at https://github.com/KhronosGroup/OpenGL-Registry
sometimes reused for other purposes -->

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note this comment (was originally in gl.xml but must've got removed):

    <!-- SECTION: GL parameter class type definitions.
         The groups are intended to contain all the possible legal values
         for corresponding function parameters, but it is likely that many
         of the groups are out of date relative to current OpenGL and OpenGL
         ES specifications, and the many extensions to those specifications.
         As such, they may not be a reliable source for enumeration info.

         We welcome assistance from the community in achieving and
         maintaining the completeness of the enum groups. Khronos does not
         use the enum group information, and the OpenGL Working Group does
         not have internal resources to bring it up to date.
    -->

This was added in #280 and #291. While thanks to community efforts this situation has got a lot better, I do think it is worth adding a comment in both files that the groups at the very least are exclusively community-supported, and that the OpenGL Working Group has no intention of keeping the groupings up-to-date themselves due to them not being relevant for Khronos uses. It's annoying we missed this comment being removed from gl.xml.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add this comment to these files too.

xml/wgl.xml Outdated
<enum value="0x21A6" name="WGL_GPU_NUM_SIMD_AMD"/>
<enum value="0x21A7" name="WGL_GPU_NUM_RB_AMD"/>
<enum value="0x21A8" name="WGL_GPU_NUM_SPI_AMD"/>
<enum value="0x21A6" name="WGL_GPU_NUM_SIMD_AMD" group="GPUProperty"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's our ruling on vendor-specific enum groups? In gl.xml this would've likely been GPUPropertyAMD. Related: #481

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with making this enum vendor specific, but I think most enum groups in gl.xml do not have a vendor postfix, even if it's mostly an extension concept. For this group, if someone else made an extension it would likely not fit into the same enum groups so it might reduce future confusion (but also, gl, wgl, and glx aren't getting that many new changes to them and probably won't).

Then there is also the fact that almost all API in wgl comes in the form of extensions, so basically all groups would need a postfix. But maybe that is what we want.

@SunSerega
Copy link
Contributor

SunSerega commented Mar 25, 2023

Yeah, when making this PR I was envisioning GL, WGL and GLX as different enum group namespaces

Hm... Is it possible for, for instance, a WGL function to accept/return an enum from gl.xml?
If it ever becomes needed in the future, how could it be denoted after separating groups into namespaces based on XML files?

@NogginBops
Copy link
Contributor Author

NogginBops commented Mar 25, 2023

Yeah, when making this PR I was envisioning GL, WGL and GLX as different enum group namespaces

Hm... Is it possible for, for instance, a WGL function to accept/return an enum from gl.xml? If it ever becomes needed in the future, how could it be denoted after separating groups into namespaces based on XML files?

Yes, this happens and is marked with a few FIXMEs comments in the PR. I guess this can be solved by making them the same namespace and add a WGL prefix to all groups defined in wgl.xml.

To me it seemed more cleaner to have them be different namespaces and figure out a way to cross reference, rather than make them the same namespace but add a prefix to the names in wgl and glx. I initially thought of it like this as it fit better into the current structure of our generator, but it's fine to change that.

There are some downsides to sharing the namespace between files, group changes in gl.xml would then have to be checked against wgl.xml and glx.xml which could very easily be forgotten, vice versa for changes in wgl.xml and glx.xml.

I think there is also another problem where some WGL functions only accept a set of enums that do not have groups defined in gl.xml, so these would have to be added to gl.xml and look like an unused group, but in fact it's used by wgl.xml and potentially glx.xml.

EDIT:
Some ideas for cross referencing enums could be something like group="gl.xml::EnumGroup", group="GL::EnumGroup", or whatever prefix we want to denote a group from another file. I think we would just have to decide on a prefix and it doesn't need to be the perfect prefix that we are all 100% happy with, just a prefix that doesn't conflict with anything and isn't obviously bad would do.

@pdaniell-nv
Copy link
Contributor

pdaniell-nv commented Mar 28, 2023

@NogginBops is this PR still a work in progress? If so, can you "convert to draft". Thanks.

@NogginBops NogginBops marked this pull request as draft March 28, 2023 22:26
@NogginBops NogginBops changed the title [WIP] Added len and group attributes to wgl.xml Added len and group attributes to wgl.xml Mar 28, 2023
@SunSerega
Copy link
Contributor

Not for this PR but...

        <command>
            <proto><ptype>__GLXextFuncPtr</ptype> <name>glXGetProcAddressARB</name></proto>
            <param>const <ptype>GLubyte</ptype> *<name>procName</name></param>
        </command>
        <command>
            <proto><ptype>__GLXextFuncPtr</ptype> <name>glXGetProcAddress</name></proto>
            <param>const <ptype>GLubyte</ptype> *<name>procName</name></param>
        </command>

I guess think would also need to be kind="gl::String"?
Feels awkward to dup kind definitions between the XML files...

@NogginBops
Copy link
Contributor Author

Not for this PR but...

        <command>
            <proto><ptype>__GLXextFuncPtr</ptype> <name>glXGetProcAddressARB</name></proto>
            <param>const <ptype>GLubyte</ptype> *<name>procName</name></param>
        </command>
        <command>
            <proto><ptype>__GLXextFuncPtr</ptype> <name>glXGetProcAddress</name></proto>
            <param>const <ptype>GLubyte</ptype> *<name>procName</name></param>
        </command>

I guess think would also need to be kind="gl::String"? Feels awkward to dup kind definitions between the XML files...

I agree these should be marked with the kind attribute.
And I'm guessing you are ok with using a prefix (gl::, wgl::, and glx::) to reference between the xml files?
I could put that into the xml spec for the group and kind tags.

@SunSerega
Copy link
Contributor

Yes, I've since rewritten my data scrappers. Had too much legacy code, your idea with group namespaces was the final push.

Right now I'm using XML files from the branch in my own fork, which has the changes from this PR plus a bunch of my own, with the namespace prefixes supported for all sorts of items, including the kinds too.

@NogginBops
Copy link
Contributor Author

Ok great then I will move forward on this assuming we are going to go with namespaces.
Will document how the namespaces work in the xml specification before marking this as ready for review.

@NogginBops
Copy link
Contributor Author

@SunSerega how do you feel about doing something like this in gl.xml:

<enum value="0x0DE1" name="GL_TEXTURE_2D" group="...,wgl::ObjectType"/>
<enum value="0x0DE1" name="GL_TEXTURE_3D" group="...,wgl::ObjectType"/>

to be able to create enum groups for wgl.xml? or should I create a group called WGLObjectType (or something like WGLObjectTypeDX)

This relates to this to the DX interop extension but will be applicable to other extensions as well
https://registry.khronos.org/OpenGL/extensions/NV/WGL_NV_DX_interop.txt

@SunSerega
Copy link
Contributor

Yeah, this also works with how I imagined it: If no namespace is specified - it defaults to the same namespace as the file name. Otherwise, any namespace can be specified.

@NogginBops
Copy link
Contributor Author

@SunSerega what do you think about my newest commit? Is it in the right direction?
It's quite small, I'm just trying to figure out how we want to structure this.

xml/wgl.xml Outdated Show resolved Hide resolved
@SunSerega
Copy link
Contributor

Since we are going for file-based namespaces, besides WGLObjectTypeDX, there are a few more groups that start with redundant WGL:

wgl::WGLColorBufferMask
wgl::WGLContextFlagsMask
wgl::WGLContextProfileMask
wgl::WGLDXInteropMask
wgl::WGLImageBufferMask
wgl::WGLLayerPlaneMask

@NogginBops
Copy link
Contributor Author

@SunSerega is this PR getting ready or is there something else needed before I can un-draft it?

Copy link
Contributor

@SunSerega SunSerega left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked everything again, LGTM.

@@ -766,6 +766,7 @@ Registry at https://github.com/KhronosGroup/OpenGL-Registry
<command>
<proto><ptype>UINT</ptype> <name>wglEnumerateVideoCaptureDevicesNV</name></proto>
<param><ptype>HDC</ptype> <name>hDc</name></param>
<!-- FIXME: Some way for len="" to refer to the return value. Maybe len="RETURN()"? -->
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SunSerega what do you think about this?
Should we introduce RETURN() or should we just leave this unhandled?

Copy link
Contributor

@SunSerega SunSerega Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't mind either way, but also while this is the only case - it doesn't matter much, since this case would need to be handled manually anyway, and IMO len attribute values are not yet consistent enough to use as notification for consumers, like "some new, yet unexpected value appeared, need to figure out how to handle this". Mainly because more than a 1/4 of them are just COMPSIZE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, I could remove this comment or leave it in.

I'll leave it to @oddhack to say whether this comments gets to stay or gets removed.

@NogginBops NogginBops marked this pull request as ready for review March 20, 2024 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants