-
Notifications
You must be signed in to change notification settings - Fork 281
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
[XML] Fixes for groups, which are supposed to differ only in vendor id's #543
base: main
Are you sure you want to change the base?
Conversation
Were only in SGI: TEXTURE_COLOR_TABLE PROXY_TEXTURE_COLOR_TABLE
Remove collision with VertexArrayPName
https://registry.khronos.org/OpenGL/extensions/PGI/PGI_misc_hints.txt Targets not explicitly accepted by glHintPGI: PERSPECTIVE_CORRECTION_HINT = C50 POINT_SMOOTH_HINT = C51 LINE_SMOOTH_HINT = C52 POLYGON_SMOOTH_HINT = C53 FOG_HINT = C54 PACK_CMYK_HINT = 800E UNPACK_CMYK_HINT = 800F PHONG_HINT = 80EB CLIP_VOLUME_CLIPPING_HINT = 80F0 TEXTURE_MULTI_BUFFER_HINT = 812E GENERATE_MIPMAP_HINT = 8192 PROGRAM_BINARY_RETRIEVABLE_HINT = 8257 CONVOLUTION_HINT = 8316 SCALEBIAS_HINT = 8322 LINE_QUALITY_HINT = 835B VERTEX_PRECLIP = 83EE VERTEX_PRECLIP_HINT = 83EF TEXTURE_COMPRESSION_HINT = 84EF VERTEX_ARRAY_STORAGE_HINT = 851F MULTISAMPLE_FILTER_HINT = 8534 TRANSFORM_HINT = 85B1 TEXTURE_STORAGE_HINT = 85BC FRAGMENT_SHADER_DERIVATIVE_HINT = 8B8B BINNING_CONTROL_HINT = 8FB0 Also note: glHintPGI's <mode> parameter takes values other then "VertexHintsMaskPGI". That group was created for: https://registry.khronos.org/OpenGL/extensions/PGI/PGI_vertex_hints.txt
Tbf I think it's probably time we take a serious look at the groups (per #481) and try and establish a sane baseline i.e. let's remove the suffixes where we think they're no longer relevant, as well as fix as many more issues as possible so we can get to a point where we're happy with what we have and move forward. e.g. BufferTargetARB probably doesn't need the ARB suffix anymore. |
xml/gl.xml
Outdated
@@ -26900,7 +26900,7 @@ typedef unsigned int GLhandleARB; | |||
</command> | |||
<command> | |||
<proto>void <name>glVertexArrayParameteriAPPLE</name></proto> | |||
<param group="VertexArrayPNameAPPLE"><ptype>GLenum</ptype> <name>pname</name></param> | |||
<param group="VertexArrayParameterNameAPPLE"><ptype>GLenum</ptype> <name>pname</name></param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc most groups use PName
instead of ParameterName
. I think changing this should be a separate issue/PR. And the APPLE
suffix isn't removed either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I didn't remove vendor suffixes when possible in this PR. However, it might be better to remove them, depending on the discussion in #481.
The reason for renaming is that VertexArrayPName
is already a group. And a separate one, with its own uses and enum values.
And tbh I'm sure there was a reason I expanded P
into Parameter
, I think something to do with functions in which this group is used. But I can't find it now.
Well, I'm all ears for naming suggestions, as always, because naming sense is not my forte.
Regardless, this PR is exactly about resolving such collisions between groups, be it by merging or splitting by renaming.
Of course, every group is its own case, but I think making a swarm of PR is a bad idea.
That said, I can make 1 PR for all the group merges and 1 PR for all splits by renaming. Do you think that would be better?
I agree with this, adding vendor suffixes to group names was a bad idea.
But this PR doesn't remove them all, because the suffix can be trivially removed on a per-binding basis, most of the time. Either because there is no group without a suffix, or because it has the same set of enum values.
I can also make a PR that removes all vendor suffixes while retaining all info of XML, but that will probably break too many things downstream.
However, there are a few cases like
ConvolutionTarget/ConvolutionTargetEXT
where both groups are meant to be one. Still, the addition of enum values to them was inconsistent. And so now they can't be merged trivially.In these cases, I merged them back into one group. And added a check to my binding generators' log, so I will notice if such behavior arises again.
I was working on this in and out before #520 got merged, and there is one more case I'd like to look into, a bit more confusing than the rest. But also I'd love some feedback. So draft for now.