KhronosGroup / KhronosGroup/OpenGL-Registry

OpenGL ES 3.0 + GL_EXT_texture_type_2_10_10_10_REV clarification

Open
#667 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
854
Forks
302
PR merge metrics
No merged PRs in 30d

Description

The [GL_EXT_texture_type_2_10_10_10_REV](https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_type_2_10_10_10_REV.txt) adds support for creating textures with an internal (and external) format of `GL_RGB` or `GL_RGBA`, and type `GL_UNSIGNED_INT_2_10_10_10_REV_EXT`.

The extension spec says the following:

> ```
> Issues
>
> 1. Should textures specified with this type be renderable?
>
> UNRESOLVED: No. A separate extension could provide this functionality.
> ```

The way I interpret this, this makes a lot of sense because the spec is written against the OpenGL ES 2.0 spec. The OpenGL ES 2.0 spec defines color-renderable as a function of the internal format, and it doesn't not mark the (unsized) internal formats `GL_RGB` or `GL_RGBA` as color-renderable, only a few sized ones.

However, OpenGL ES 3.0 marks the unsized `GL_RGB` and `GL_RGBA` internal formats as color-renderable, with the following wording:

> An internal format is color-renderable if it is one of the formats from table 3.13 noted as color-renderable or if it is unsized format RGBA or RGB.

The way I interpret this, the result of supporting `GL_EXT_texture_type_2_10_10_10_REV` in an OpenGL ES 3.0 context, would be that the a texture created with an internal/external format of `GL_RGB` / `GL_RGBA` and a type of `GL_UNSIGNED_INT_2_10_10_10_REV_EXT` would be color-renderable. In effect, the "A separate extension could provide this functionality" bit is covered by a later OpenGL ES version.

Is this interpretation correct?

The reason I'm asking, is that the CTS test case `dEQP-GLES2.functional.fbo.completeness.renderable.texture.color0.rgba_unsigned_int_2_10_10_10_rev` checks for the exact opposite; it expects the result to *not* be color-renderable. And I'm having a hard time interpreting the spec in this direction. But it seems [a lot of implementations](https://opengles.gpuinfo.org/listreports.php?extension=GL_EXT_texture_type_2_10_10_10_REV) implement this extension on top of OpenGL ES 3.x, and I assume they're passing the CTS. So did everyone but me get this wrong, or is there some detail I'm just not getting here?

It's also worth noting that OpenGL ES 3.0 also marks the sized internal format of `GL_RGB10_A2` as color-renderable, so it's not as if rendering to RGB10A2 textures was intended to not be supported. It just seems like an omission when adding OpenGL ES 3.0 support to the CTS to me.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the GL_EXT_texture_type_2_10_10_10_REV specification alongside the OpenGL ES 3.0 color-renderable wording. Review the CTS test case dEQP-GLES2.functional.fbo.completeness.renderable.texture.color0.rgba_unsigned_int_2_10_10_10_rev and determine whether its expectation matches the applicable specification; done means documenting and, if warranted, correcting the agreed interpretation.

Written by the indexing model from the issue text.

Assessment

Domain
computer-graphics, testing
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.