KhronosGroup / KhronosGroup/OpenGL-Registry

OpenGL ES 2.0 unsized format color-renderable clarification

Open
#669 2 comments 1 reaction 0 assignees View on GitHub
Dominant language
C
Stars
854
Forks
302
PR merge metrics
No merged PRs in 30d

Description

## Background

The OpenGL ES 2.0 spec says this about color-renderable formats (emphasis mine):

> The internal formats of the attached images can affect the completeness of
the framebuffer, so it is useful to first define the relationship between the internal
format of an image and the attachment points to which it can be attached. Image
internal formats are summarized in table 4.5. **Color-renderable formats contain
red, green, blue, and possibly alpha components; depth-renderable formats contain
depth components; and stencil-renderable formats contain stencil components.**
>
>**Formats not listed in table 4.5, including compressed internal formats. are not
color-, depth-, or stencil-renderable, no matter which components they contain.**

However, in the OpenGL ES 3.0 spec, this was changed to say (again, emphasis mine):

> The internal formats of the attached images can affect the completeness of
the framebuffer, so it is useful to first define the relationship between the internal
format of an image and the attachment points to which it can be attached.
> * An internal format is color-renderable if it is one of the formats from ta-
ble 3.13 noted as color-renderable **or if it is unsized format RGBA or RGB**. No
other formats, including compressed internal formats, are color-renderable.

It's not entirely clear to me if the phrasing "Color-renderable formats contain red, green, blue, and possibly alpha components"-bit is meant to convey the same thing as in the ES3 spec; unsized RGB and RGBA being color-renderable. Especially because of the phrasing "Formats not listed in table 4.5, including compressed internal formats. are not color-, depth-, or stencil-renderable, no matter which components they contain.". And table 4.5 does not contain any unsized formats -- In fact, it cannot, because the column for internal formats is called "Sized Renderable Internal Format".

This topic been *sorta* been addressed before, on the Khronos Bugzilla: https://www.khronos.org/members/login/bugzilla/show_bug.cgi?id=8909

However, that issue is explicitly about renderbuffers. And the conclusion in that discussion seems to be that unsized RGB and RGBA are *indeed* color-renderable, but specifically illegal to use for renderbuffers (as a result of the wording change proposed in that ticket).

In addition, there's this ticket that discuss the renderability of FBOs with textures attachments with unsized internal formats:
https://www.khronos.org/members/login/bugzilla/show_bug.cgi?id=7333

In this ticket, it's actually suggested that this isn't actually under-specified, but that the working group *intended* to introduce wording that made unsized internal formats color-renderable if some unspecified mapping between the type/format used during upload to a sized internal format is color-renderable.

However, no such wording got introduced, and the ticket eventually got closed as WONTFIX. This arguably leaves the color-renderability of unsized internal-formats unspecified for GLES 2. Or as color-renderable. It's hard to tell, really.

Finally, we have the CTS, which, uh... does *something*. For instance, the `GLES2.functional.fbo.completeness.renderable.texture.color0.*`-tests, generally seems to think there's well-known format/type pairs that are allowed to be color-renderable. The pairs seems to have been added somewhat randomly, and not based on clear phrasing found in the spec or any consistent logic. For one example, see #667.

But more generally, it seems to me that the idea of this implicit mapping from the issue tracker are even kinda contradicted by the CTS. For instance, the CTS claims that RGB/RGBA + FLOAT can't ever be color-renderable, even if `EXT_color_buffer_float` is supported (which would mean we have a sized internal-format that matches).

Now, it's been about 15 years since anything happened on this front from what I can tell, and things are still IMO confusing.

## Questions

1. Are the unsized internalformats rules for GLES 2 and GLES 3 supposed to be different?

2. Are the unsized internalformats GL_RGB and GL_RGBA intended to be color-renderable in GLES 3.0 regardless of the format and type used when uploading them, like the spec seems to pretty clearly suggest?

3. Should we clarify the spec here?

4. Should the CTS be changed to match the spec, or should the spec be changed to match the CTS here?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by comparing the OpenGL ES 2.0 and 3.0 framebuffer completeness wording with the linked Bugzilla issues 8909 and 7333. Review the CTS tests under GLES2.functional.fbo.completeness.renderable.texture.color0.* and the related issue #667; the work is done when the intended unsized-format rules are decided, the specification is clarified if needed, and the CTS agrees.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, testing-qa
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.