Removed "len" XML attribute from "pointer" parameter declarations of "glVertexAttribIPointerEXT", "glVertexAttribLPointerEXT" and "glVertexAttribPointerARB" commands

KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry

677 stars 274 forks source link

Removed "len" XML attribute from "pointer" parameter declarations of "glVertexAttribIPointerEXT", "glVertexAttribLPointerEXT" and "glVertexAttribPointerARB" commands #598

Closed Rytis-Stan closed 9 months ago

Rytis-Stan commented 9 months ago

The removal was done because the "pointer" parameter is not mean to act as an array, but simply as a relative integer offset when defining vertex attributes. An equivalent fix was done previously for the related commands: "glVertexAttribIPointer", "glVertexAttribLPointer" and "glVertexAttribPointer" (related PR: https://github.com/KhronosGroup/OpenGL-Registry/pull/592)

NogginBops commented 9 months ago

I don't have much of an opinion on this, but it does seem like glVertexAttribIPointerEXT should actually just take a pointer to an array of indices directly if I'm reading the specification right as the EXT_gpu_shader4 is written on top of OpenGL 2.0.

Not sure what is expected of a driver that implements these methods, it would make sense they they would follow modern glVertexAttribPointer* conventions but I'm not sure if this is what the spec really says...

But I guess glVertexAttribPointerARB from either GL_ARB_vertex_shader or GL_ARB_vertex_program should behave identically to glVertexAttribPointer in modern drivers so I guess that is how it's supposed to be?

Maybe someone from Khronos can clarify the intended behavior for these functions.

Rytis-Stan commented 9 months ago

Maybe someone from Khronos can clarify the intended behavior for these functions.

Yes, it would be nice if someone could comment more on these functions.

pdaniell-nv commented 9 months ago

The "EXT" variants of these functions were all promoted to the non-EXT core versions, so I think all drivers will treat them as aliases and therefore implement them in exactly the same way.

NogginBops commented 9 months ago

Is that how promotion of functions are "supposed" to be handled or is this just how it works in practice? Either way I think this answered my question.

pdaniell-nv commented 9 months ago

In most cases yes promoted functions become just aliases in the implementation. There are some cases where there is a small divergence between the extension function and the core function, due to spec differences in the function behavior, in which case typically a subset of the function implementation is common. In this case they are aliases.

oddhack commented 9 months ago

TL;DR "promotion" does not mean "identical behavior", rather "functionally very similar".

We don't actually tag aliases in gl.xml (unlike the Vulkan XML). There are several possible interpretations of 'alias' for GL commands:

Client alias in libGL.so - calling the two functions goes to the same client code via thunks or loader features or whatever.
GLX protocol alias - different entry points in libGL.so that create the same GLX protocol which lands in the same place in the driver (and the same thing in direct rendering).
Different client and driver entry points, which might or might not have somewhat different behavior (hopefully called out in the spec or extension document, if so).

pdaniell-nv commented 9 months ago

@oddhack this is approved to merge.