Add GL_EXT_ES1_compatibility #451
Conversation
|
Doing an extension requires more than just adding the functions to the XML, it also needs to be documented (see https://www.khronos.org/registry/OpenGL/index_gl.php). You would probably make quicker progress making this a vendor or EXT extension rather than an ARB extension. ARB extensions require ratification from the Khronos board, as well as 3+ implementations and CTS. Who are you hoping will implement this? NVIDIA have something similar called GL_NV_ES1_1_compatibility, which was never published. That extension seems to expose a lot more functions than the 4 you have exposed here. GLAPI void GLAPIENTRY glAlphaFuncx (GLenum func, GLclampx ref);
GLAPI void GLAPIENTRY glClearColorx (GLclampx red, GLclampx green, GLclampx blue, GLclampx alpha);
GLAPI void GLAPIENTRY glClearDepthx (GLclampx depth);
GLAPI void GLAPIENTRY glClipPlanef (GLenum plane, const GLfloat *equation);
GLAPI void GLAPIENTRY glClipPlanex (GLenum plane, const GLfixed *equation);
GLAPI void GLAPIENTRY glColor3x (GLfixed red, GLfixed green, GLfixed blue);
GLAPI void GLAPIENTRY glColor4x (GLfixed red, GLfixed green, GLfixed blue, GLfixed alpha);
GLAPI void GLAPIENTRY glDepthRangex (GLclampx zNear, GLclampx zFar);
GLAPI void GLAPIENTRY glFogx (GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glFogxv (GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
GLAPI void GLAPIENTRY glFrustumx (GLfixed left, GLfixed right, GLfixed bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
GLAPI void GLAPIENTRY glGetClipPlanef (GLenum plane, GLfloat *eqn);
GLAPI void GLAPIENTRY glGetClipPlanex (GLenum plane, GLfixed *eqn);
GLAPI void GLAPIENTRY glGetFixedv (GLenum pname, GLfixed *params);
GLAPI void GLAPIENTRY glGetLightxv (GLenum light, GLenum pname, GLfixed *params);
GLAPI void GLAPIENTRY glGetMaterialxv (GLenum face, GLenum pname, GLfixed *params);
GLAPI void GLAPIENTRY glGetTexEnvxv (GLenum env, GLenum pname, GLfixed *params);
GLAPI void GLAPIENTRY glGetTexParameterxv (GLenum target, GLenum pname, GLfixed *params);
GLAPI void GLAPIENTRY glLightModelx (GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glLightModelxv (GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glLightx (GLenum light, GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glLightxv (GLenum light, GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glLineWidthx (GLfixed width);
GLAPI void GLAPIENTRY glLoadMatrixx (const GLfixed *m);
GLAPI void GLAPIENTRY glMaterialx (GLenum face, GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glMaterialxv (GLenum face, GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glMultiTexCoord1x (GLenum target, GLfixed s);
GLAPI void GLAPIENTRY glMultiTexCoord1xv (GLenum target, const GLfixed *v);
GLAPI void GLAPIENTRY glMultiTexCoord2x (GLenum target, GLfixed s, GLfixed t);
GLAPI void GLAPIENTRY glMultiTexCoord2xv (GLenum target, const GLfixed *v);
GLAPI void GLAPIENTRY glMultiTexCoord3x (GLenum target, GLfixed s, GLfixed t, GLfixed r);
GLAPI void GLAPIENTRY glMultiTexCoord3xv (GLenum target, const GLfixed *v);
GLAPI void GLAPIENTRY glMultiTexCoord4x (GLenum target, GLfixed s, GLfixed t, GLfixed r, GLfixed q);
GLAPI void GLAPIENTRY glMultiTexCoord4xv (GLenum target, const GLfixed *v);
GLAPI void GLAPIENTRY glMultMatrixx (const GLfixed *m);
GLAPI void GLAPIENTRY glNormal3x (GLfixed nx, GLfixed ny, GLfixed nz);
GLAPI void GLAPIENTRY glOrthof (GLfloat left, GLfloat right, GLfloat bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
GLAPI void GLAPIENTRY glOrthox (GLfixed left, GLfixed right, GLfixed bottom, GLfixed top, GLfixed zNear, GLfixed zFar);
GLAPI void GLAPIENTRY glPointParameterx (GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glPointParameterxv (GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glPointSizex (GLfixed size);
GLAPI void GLAPIENTRY glPolygonOffsetx (GLfixed factor, GLfixed units);
GLAPI void GLAPIENTRY glRotatex (GLfixed angle, GLfixed x, GLfixed y, GLfixed z);
GLAPI void GLAPIENTRY glSampleCoveragex (GLclampx value, GLboolean invert);
GLAPI void GLAPIENTRY glScalex (GLfixed x, GLfixed y, GLfixed z);
GLAPI void GLAPIENTRY glTexEnvx (GLenum target, GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glTexEnvxv (GLenum target, GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glTexParameterx (GLenum target, GLenum pname, GLfixed param);
GLAPI void GLAPIENTRY glTexParameterxv (GLenum target, GLenum pname, const GLfixed *params);
GLAPI void GLAPIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z); |
|
+1 The reason these functions aren't present is because no implementation exposes them. Generally it's the people writing the drivers that update the spec with the cool new features they've decided to put into their driver. There's not much we can do not being driver developers I'm afraid. EDIT: If they do expose them, however, they should definitely update the spec! We just need confirmation that this extension is properly implemented. |
|
I do not consider the fixed-point support defined for the common lite profile. |
|
Sure, if you don't need the fixed-point functions then the 4 you proposed would be enough. And yes you would need to write up a GL_EXT_ES1_compatibility extension. |
|
I'm happy to write up a textual specification if you can get one of the Mesa devs in here so that they know what's going on such that they can support the extension from their end. |
|
Enh. I'm not super thrilled with pretending ES1 is still a thing, but Mesa builds the thunk functions unconditionally so I suppose it's free to advertise. But if we were going to do that I'd prefer we just document the NV extension (where by "we" I guess I mean "NVIDIA"). Practically speaking if Mesa implemented an EXT-named version we'd probably go ahead and expose the NV string as well for compatibility, since if there is any code out there wanting ES1 compat then that's what it's already checking for, so having an EXT string seems a bit pointless. |
|
The NVIDIA extension is significantly larger, so it would may require some work. But if all the functions Piers listed previously are built unconditionally as you said then yeah we could probably go down this route, or maybe promote the NVIDIA extension to EXT as I doubt that NVIDIA will have a lot of cycles going for stuff like this. |
It's not any larger in the sense that Mesa already implements ES1, all the extra ES1 entrypoints are thunks into the big-GL versions, and we build that code into the driver unconditionally. So adding them to big-GL is really just allowing Also I'm somewhat alarmed to see NVIDIA's driver exposes "Promoting" the extension to EXT is exactly what I'm not interested in though. If there's any code in the world that wants this, then it already exists and is looking for the NVIDIA string. Adding an EXT version just means they'd have to update their code to check for two things, and any app that didn't do that would fail with an impl that only exposed the EXT string, so we'd end up exposing both anyway, so why bother. This isn't unusual, we support plenty of "NV" extensions and at least a few from various vendors that don't exist in the registry IIRC. If all we're really trying to do is make this exist in Mesa then there's no reason to involve the registry, other than it'd be polite for NVIDIA to document it. |
|
I see. In which case @caramelli an issue should be opened for NVIDIA to document this extension. You can use the header snippet that Piers posted to wield these functions, and will be able to use the old NVIDIA string on some NVIDIA devices and Mesa drivers once exposed. I don't think the EXT extension will be taken further if this is the Mesa's stance, the only other vendor to implement this extension. |
|
Mesa is useful for testing this OpenGL ES 1.1 compatibility, but it goes beyond that. Looking at the links between the different OpenGL specifications, it seems to me that it makes sense to have this compatibility (just 4 missing functions if we don't consider the fixed-point support defined for the common lite profile). Bringing this consistency has nothing to do with NVIDIA, this unknown compatibility name GL_NV_ES1_1_compatibility seems really strange to me for this kind of compatibility. Just to be sure that I understood: you suggest to use this name "GL_NV_ES1_1_compatibility" absent from the OpenGL-Registry and to submit a merge request of this "GL_NV_ES1_1_compatibility" extension to Mesa. |
What I'm proposing is that the Mesa MR add everything that @pdaniell-nv says is added by I don't really understand why you think that's a "limited compatibility", or what consistency you're trying to propose. To me, what'd be consistent is if everyone exposes the same extension string for the same functionality. And since one vendor's already defined what the extension string is for that functionality, I don't see why we don't just all use that. It's unfortunate that it's not in the registry yet, sure, but that can change, and both NVIDIA and Mesa have a long history of shipping unregistered extensions, so... |
|
Using the existing NV one is more conservative and it allows code to just work that already uses this internal extension (NVIDIA partners?) which is present on many devices today. Fully in agreement with @nwnk here, but we may require some co-ordination from NVIDIA in registering this extension. @pdaniell-nv I could draft up a spec and perhaps someone from NV could look at it if this is acceptable to you? Of course, ideally NVIDIA should be writing this spec in its entirety, but again I'd imagine you don't have many cycles going for stuff like this. |
|
Sure if you are willing to knock up a spec I can review and approve. Thanks. |
|
Awesome, can you advise on what tokens this extension has? |
|
There are no additional tokens beyond what's already in OpenGL compatibility profile, just those function entry points are new. For others that want to implement this extension, once implemented it should pass ES11 CTS. |
|
In terms of the actual spec content, there are a bunch of places that need to handle GL_FIXED, mostly related to vertex attribute types. I don't see anything else beyond that that needs to be supported at a quick glance. |
|
Affirmative, thanks. Will stitch something together. Should the contact for this extension be a NVIDIA contact or should I put my name in there? |
|
Thanks @nwnk for these clarifications! OK, it's not a "limited compatibility" if registered. Adding everything defined by GL_NV_ES1_1_compatibility is much more important than I had initially imagined! I never played with the fixed-point support defined for the common lite profile. I have no problem with anything defined by GL_NV_ES1_1_compatibility, but as just explained, the approach is slightly different. @Perksey, is there something I need to do? |
It should be fine for now. I'm going to stitch together a technical, textual specification and update the XML for these functions. Once approved by NVIDIA, this extension will be present in the headers. |
You should probably to mine, unless you want to risk taking responsibility for something that's not totally under your control. You should put your name in the revision history for revision 1. |
|
@caramelli yeah, it's a bit different from what you were proposing, but since Mesa does already have the code for the fixed-point support we may as well expose all of what the NV extension does just to be completely compatible. Thanks for being flexible, I look forward to working with you through the Mesa merge process! |
+1 @nwnk - Are you sure these function should just work on desktop GL? I thought we would return Since Mesa and NVIDIA both allow creating a real, conformant ES 1.x context... why not just use the real thing? |
|
My proposed version will likely be heavily based on OES_fixed_point in
writing so it might be worth looking at how that’s handled today.
…On Thu, 14 Jan 2021 at 01:47, Ian Romanick ***@***.***> wrote:
I'm not super thrilled with pretending ES1 is still a thing, ...
+1
@nwnk <https://github.com/nwnk> - Are you sure these function should just
work on desktop GL? I *thought* we would return GL_INVALID_OPERATION for
functions that don't exist in a particular profile. ES1 / ES2 / desktop GL
have a ton of subtle differences in error handling, glReadPixels /
glDrawPixels, and texture internal formats. It took us a really, really
long time to get that stuff "right" in Mesa, and I'd really hate to
complicate that fragile code any further.
Since Mesa and NVIDIA both allow creating a real, conformant ES 1.x
context... why not just use the real thing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#451 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACVEYI3NEA7NAJE3PPEECJLSZZELZANCNFSM4UW4G25Q>
.
|
|
Haven't spent much more time looking at this, personally don't have much motivation to do so given that OES_single_precision and OES_fixed_point cover most of NV_ES_1_1_compatibility, just with the OES suffix on the functions. If someone still wanted to create a spec for NV_ES_1_1_compatibility I would use those two extensions as a starting point. |
I am curious where the list comes from |
|
Those are the entry points the NVIDIA driver exposes to support OpenGL ES 1.1 and pass its conformance tests. |
|
It should be noted that the mentioned GL_NV_ES1_1_compatibility extension is now available also in Mesa. 👍 I can confirm this for Mesa 22.3.0-devel (git-ef27399 2022-08-27). More information can be found at the corresponding MR !18217 |
I am using OpenGL ES 1.1 code with an OpenGL implementation (GL headers and libGL library).
Everything is OK except the declaration of 4 prototypes which are missing for compatibility.
So I just define GL_ARB_ES1_compatibility to add them (similar to GL_ARB_ES2_compatibility).
But that may not be the right way to do it.
Nicolas Caramelli