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

[Nicolai Hähnle]

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 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?

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.

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. It's pretty ridiculous though that apparently the 
spec doesn't even mandate that RGBA8 must be renderable.

Cheers,
Nicolai


>
> On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Right, but it'd break st/nine which doesn't (didn't?) support
>> fallbacks like st/mesa does.
>>
>> I'm trying to better understand what the required logic is based on
>> the spec, not how to fix this particular application's rendering with
>> nouveau (which I'm much less concerned about, tbh).
>>
>>   -ilia
>>
>> On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> Dropping texturing support for RGBA4 would resolve that issue.
>>>
>>> Marek
>>>
>>> On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> Hello,
>>>>
>>>> Is there a concept in OpenGL that certain internal formats *must* be
>>>> supported for rendering? An issue we're running into is that NVIDIA
>>>> hardware supports sampling from RGBA4 textures, but does not support
>>>> that as a render format. So if you create a tex image with GL_RGBA4,
>>>> we use that as the TexFormat, since we can sample from it. However
>>>> then attaching the image to a fbo makes that fbo incomplete.
>>>>
>>>> At least one application isn't ready to handle that situation. Is the
>>>> application wrong, or must we support GL_RGBA4 as a renderable texture
>>>> attachment format, thus meaning that we should never actually make use
>>>> of the hw's RGBA4 sampling capabilities (since we never know if a
>>>> texture will later be used for rendering)?
>>>>
>>>> The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core
>>>> spec marks GL_RGBA4 as "required renderable", but I think that only
>>>> affects renderbuffers (which st/mesa handles properly by falling back
>>>> to RGBA8 when the requested format is not renderable).
>>>>
>>>> Any advice welcome.
>>>>
>>>> Cheers,
>>>>
>>>>   -ilia
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>