[Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

[Daniel Stone]

Hi,

On 28 June 2017 at 19:09, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> i965 tries pretty hard to allocate sRGB images in the pre-DRIImage,
>> DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't
>> used by Wayland, GBM, or DRI3.
>
> Except that whether you get an sRGB renderbuffer or not is governed by GLX
> and EGL and not Wayland/DRI2/DRI3.  In one of them (I think it's ES), the
> default is to get an sRGB renderbuffer but either is possible with both
> independent of how the image comes in.  We *do* see it on DRI3 and Wayland
> which is why this patch exists in the first place.

Well, that's fairly depressing. So I guess SARGB8 is only used for
GLX_ARB_framebuffer_sRGB, and the rest is just magically transforming
(ostensibly) _UNORM Mesa formats into _SRGB?

intel_gles3_srgb_workaround() is ... quite a thing.

>> So no, not for pretty much any externally-visible images AFAICT. Even
>> if it were true for scanout, the client would need to tell KMS, so KMS
>> could send a HDMI infoframe telling the display.
>
> But scanout always does sRGB.  If you want real UNORM, then you'll have to
> add kernel API.

I'm kinda confused on this point; the colour transform matrix set up
by default is an identity mapping, rather than a degamma-to-linear
(ignoring the 16-235 vs. limited dance ...). In theory, if we're
sending sRGB, we should inform the sink via an AVI infoframe, but I
can't see anywhere we actually do that.

Anyway, I don't see this patch making the historical mistake any
better or worse, so let's just mentally file it away to bottom out one
day and move on.

Cheers,
Daniel