gl.xml: TextureStorage extension 1D/3D entry points conditional, and EXT missing from desktop

[null77]

There's two slight issues that may be present with gl.xml's information on GL_EXT_texture_storage (and also potentially some overlap with GL_ARB_texture_storage).

1. The EXT extension specifies:

In particular, note that OpenGL ES 1.x/2.0 do not have proxy textures,
1D textures, or 3D textures, and thus only the TexStorage2DEXT
entry point is required. If OES_texture_3D is supported, the
TexStorage3DEXT entry point is also required.

The ARB spec is specified against OpenGL ES 1.0 and OpenGL ES 2.0, which do not have 1D/3D textures but I didn't see any mention of the conditional exposure. Seems like an oversight - in any case this information is missing from gl.xml that I saw.

2. The EXT extension is specified against OpenGL ES 1.0, OpenGL ES 2.0 or OpenGL 1.2 but gl.xml does not include it as a desktop GL extension. Conversely for ARB, it is also specified as OpenGL ES 1.0, OpenGL ES 2.0 or OpenGL 1.2, but gl.xml does not list it for gles APIs. Not sure if this is intentional.

@oddhack can you provide any clarification here? It was something we noticed when implementing an entry point loader via gl.xml.

[oddhack]

I don't believe there's any way to express that an extension only supports some interfaces in specific API versions. We can do <require api="apiname"> but that only applies at the level of apinames that are used in the XML, which is just GL, GL core profile, ES 2.* and above, and ES 1.*. Short of extending the schema and the scripts that process it, the best we could do is move these commands into <require comment=> blocks that note the interaction in the comment field, but that information wouldn't be useful to automated processing.

N.b. there's a similar issue especially visible with EXT_direct_state_access, where most of the commands are only relevant if specific other extensions are supported at runtime, and the same tactic of noting the interaction in the comment= field was used.

For purposes of the headers this is sufficient because the headers are supposed to define all extension interfaces, but it's a real omission. I agree that it should be fixed, but it would be a lot of work that we probably don't have resources for at present.