Khronos public bugtracker – Bug 689
Internalformat_query2's interactions with FBO support not well specified
Last modified: 2013-08-15 11:37:46 PDT
Internalformat_query2 allows you to query GL_FRAMEBUFFER_RENDERABLE. All well and good. But it doesn't really say what it means for it to have FULL_SUPPORT. It just says:
The support for rendering to the resource via framebuffer attachment is returned in <params>
What I mean is this: GL_FRAMEBUFFER_UNSUPPORTED is allowed to happen by the spec for the use of formats that aren't supported, or the use of a combination of formats that aren't be supported. However the spec sets aside a number of formats which are not allowed to return GL_FRAMEBUFFER_UNSUPPORTED. You can use any combination of any of these formats and the implementation is required to accept it.
If I test a format that isn't on OpenGL's required list, and it returns FULL_SUPPORT, does that mean that I can never get UNSUPPORTED if I use it? No matter what? The spec doesn't say. The exact behavior is not detailed, only that it is "supported".
I think section 9.4.3 should be amended as follows. It should be:
> Implementations must support framebuffer objects with up to MAX_COLOR_ATTACHMENTS color attachments, a depth attachment, and a stencil attachment. Each color attachment may be in any of the required color formats for textures and renderbuffers described in sections 8.5.1 and 9.2.5. The depth attachment may be in any of the required depth or combined depth+stencil formats described in those sections, and the stencil attachment may be in any of the required combined depth+stencil formats. However, when both depth and stencil attachments are present, implementations are only required to support framebuffer objects where both attachments refer to the same image.
> Any internal format that offers FULL_SUPPORT from the FRAMEBUFFER_RENDERABLE query can be used in non-layered attachments in any combination with other required formats or formats that offer FULL_SUPPORT. Any internal format that offers FULL_SUPPORT from the FRAMEBUFFER_RENDERABLE_LAYERED may be used in any combination with other required formats or formats that offer FULL_SUPPORT.
This would give the query some actual teeth, because right now, it's not clear what it means to fully support FRAMEBUFFER_RENDERABLE. Also, it explains what CAVEAT support means: that the format can be used in certain combinations with other formats, but it's not guaranteed to work in combination with all other fully supported formats. NONE obviously means that it can never be renderable no matter what.
The original intent of this extension was more about querying capabilities and feature discovery than providing guarantees. It is true that by looking at (say) the GL 4.3 spec you can tell what formats are guaranteed to be renderable from the spec language. However if you think about this from the point of view of an application that may be able to run an implementations anywhere from GL 2.0 to GL 4.4 (or maybe even GL ES), it wouldn't be nice to have to hardcode what formats are renderable for every (or even just the interesting) API versions into the app (and that doesn't even consider extensions, or additional formats that an implementation may support above and beyond the required ones). Failing that, the app might have to write startup tests to actually try rendering to the interesting formats. This extension was intended to help address that.
WRT to "what is the difference between FULL_SUPPORT and CAVEAT_SUPPORT for FRAMEBUFFER_RENDERABLE", my expectation is that any format that doesn't have any weird corner cases, interactions with certain types of state, or particularly poor performance characteristics, would be listed as FULL_SUPPORT. If it had any of those, I'd want a driver to report CAVEAT_SUPPORT and log more details of the caveat to the debug log. Ideally anything on the required format list would have FULL_SUPPORT, but I would rather have a caveat be acknowledged than hidden just because that HW couldn't support a specific API version if it was acknowledged.
Examples of a couple caveats that I've encountered in the past / could imagine are:
- formats that you can't renderer to with blending enabled (like float formats on some older HW)
- formats that don't have a nice stride that an implementation might have to replace under the covers with another format (eg RGB8 vs RGBA8)
Trying to guarantee avoidance of FRAMEBUFFER_UNSUPPORTED is certainly a great goal, but that was't the purpose of this query. I do see this extension / function as a step in that direction though.
The other factor which this extension doesn't address is issues that could arise as a product of a *combination* of framebuffer attachments. (Think for example of HW that maybe has limited rendering bw, and if the total bitrate of all the attached framebuffer formats exceeded some amount, would operate at a reduced performance level.)
We could consider adding language like you suggested in a future version if that is something you'd like us to consider, but I would consider that an enhancement request.