<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 28 June 2017 at 16:35, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
</span><span class="">>> On 28 June 2017 at 02:05, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
>> > The long answer is that the DRI formats do not specify a colorspace.<br>
>><br>
>> Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a<br>
>> colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is<br>
>> equivalent to the latter, bar the addition of a special and unique<br>
>> SARGB8 token, i.e. ARGB8888 with the sRGB transfer function (and<br>
>> presumably primaries?). The rest are presumed UNORM.<br>
><br>
> Wha?  What's the difference between SARGB8 and ARGB8888 then?  My<br>
> understanding was that scanout basically treats everything as sRGB anyway.<br>
> Clearly, my sRGB knowledge is imperfect.<br>
<br>
</span>GBM_FORMAT_ARGB8888 (aka DRI_IMAGE_FOURCC_ARGB8888), gets mapped to<br>
DRI_IMAGE_FORMAT_ARGB8888, which gets mapped to<br>
MESA_FORMAT_B8G8R8X8_UNORM (dri_util.c). Only<br>
DRI_IMAGE_{FORMAT,FOURCC}_<wbr>SARGB8 (no defined GBM token, but you can<br>
pass it through the GBM API and it'll work sometimes) gets mapped to a<br>
MESA_FORMAT_*_SRGB. So AFAICT, to get an sRGB scanout buffer from<br>
Mesa/GBM, you'd need to allocate UNORM and do inverse-gamma in your<br>
frag shader.<br>
<br>
Wayland similarly never maps anything to sRGB.<br>
<br>
X11 always imports EGLImages as UNORM, so blending would be broken in<br>
a composited environment if we were actually allocating sRGB.<br></blockquote><div><br></div><div>Blending *is* broken.  I had a long chat with Owen Taylor about this some time ago.  Everything comes into X11 sRGB encoded and scanout treats it's buffer as sRGB.  X11 then stomps everything to UNORM and blends in the wrong colorspace.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i965 tries pretty hard to allocate sRGB images in the pre-DRIImage,<br>
DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't<br>
used by Wayland, GBM, or DRI3.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So no, not for pretty much any externally-visible images AFAICT. Even<br>
if it were true for scanout, the client would need to tell KMS, so KMS<br>
could send a HDMI infoframe telling the display.<br></blockquote><div><br></div><div>But scanout always does sRGB.  If you want real UNORM, then you'll have to add kernel API.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Colourspaces \_o_/<br>
<span class=""><br>
> As for enums, sure, that can probably happen.  GL and ISL both have enums<br>
> for colorspace that we could re-use.<br>
<br>
</span>Yes, having too few format tokens is not a problem we have. We seem to<br>
have about as many of those as we have things called 'DRI2'.<br>
</blockquote></div><br></div><div class="gmail_extra">Heh<br></div></div>