[Mesa-dev] Required-for-rendering internal formats

[Erik Faye-Lund]

On Thu, Oct 13, 2016 at 5:35 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 13.10.2016 17:15, Ilia Mirkin wrote:
>>
>> Anyone else have opinions on this? Should st/mesa be adding
>> PIPE_BIND_RENDER_TARGET for all textures of the internal formats
>> listed in table 8.12? (Which would, in this case, force RGBA8 to be
>> used since RGBA4 is non-renderable.) Or is it perfectly legal for a
>> format to be not renderable when used as a texture vs renderbuffer?

I have some old patches laying around that I've been intending to
upstream for a while in this area:

https://github.com/kusma/mesa/commits/color_renderable_fix

IIRC, some work has landed since that made some of the patches
obsolete, so take things with a grain of salt ;)

>
> I think the spec is pretty clear that the "req.rend." column of that table
> is only for renderbuffers.
>
> It's a lot less clear about what really matters for this question. In
> section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:
>
>     Each color attachment may be in any of the color-renderable
>     formats described in section 9.4 (although implementations
>     are not required to support creation of attachments in all
>     color-renderable formats).
>
> Color-renderable formats are those which have a checkmark in the CR column
> according to section 9.4. That means pretty much _all_ non-compressed
> formats (except for the shared exponents one). I doubt that the intention is
> to force stuff like R3_G3_B2 to be renderable.
>
> It's kind of funny that the sentence says that the attachments may be in any
> of these formats, but you may not be able to create the attachments?

You can create any attachments as long as you can create the texture
or renderbuffer for them. And all formats are marked as either req.ren
or req.tex. So any format might be attached. But that doesn't mean it
can be *rendered* to.

> I think what that's trying to say is that the implementation MUST reject
> color attachments that are not CR according to table 8.12, and it MAY reject
> color attachments of any format it likes.
>

In essence, yes. But the details are of course a bit more complicated.

Everything marked as CR is "color renderable" according to OpenGL.
However, being "color renderable" isn't *enough* to guarantee that it
can be rendered to, because of framebuffer completeness:

Section 9.4.2 ("Whole Framebuffer Completeness") of the OpenGL 4.5
core spec says:

"Although the GL defines a wide variety of internal formats for
framebufferattachable images, such as texture images and renderbuffer
images, some implementations may not support rendering to particular
combinations of internal formats. If the combination of formats of the
images attached to a framebuffer object are not supported by the
implementation, then the framebuffer is not complete under the clause
labeled FRAMEBUFFER_UNSUPPORTED."

So, using a non-CR format produces
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT, and using a non-supported CR
format produces FRAMEBUFFER_UNSUPPORTED.

> So I tend to side with the interpretation that exposing RGBA4 as texture
> format but not allowing to render to it is okay by the spec, and the
> application has a bug.

This is my interpretation as well.