On Wed, Jun 28, 2017 at 11:09 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone <dan...@fooishbar.org> > wrote: > >> Hi, >> >> On 28 June 2017 at 16:35, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> > On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone <dan...@fooishbar.org> >> wrote: >> >> On 28 June 2017 at 02:05, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> >> > The long answer is that the DRI formats do not specify a colorspace. >> >> >> >> Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a >> >> colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is >> >> equivalent to the latter, bar the addition of a special and unique >> >> SARGB8 token, i.e. ARGB8888 with the sRGB transfer function (and >> >> presumably primaries?). The rest are presumed UNORM. >> > >> > Wha? What's the difference between SARGB8 and ARGB8888 then? My >> > understanding was that scanout basically treats everything as sRGB >> anyway. >> > Clearly, my sRGB knowledge is imperfect. >> >> GBM_FORMAT_ARGB8888 (aka DRI_IMAGE_FOURCC_ARGB8888), gets mapped to >> DRI_IMAGE_FORMAT_ARGB8888, which gets mapped to >> MESA_FORMAT_B8G8R8X8_UNORM (dri_util.c). Only >> DRI_IMAGE_{FORMAT,FOURCC}_SARGB8 (no defined GBM token, but you can >> pass it through the GBM API and it'll work sometimes) gets mapped to a >> MESA_FORMAT_*_SRGB. So AFAICT, to get an sRGB scanout buffer from >> Mesa/GBM, you'd need to allocate UNORM and do inverse-gamma in your >> frag shader. >> >> Wayland similarly never maps anything to sRGB. >> >> X11 always imports EGLImages as UNORM, so blending would be broken in >> a composited environment if we were actually allocating sRGB. >> > > 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. > > >> 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. > Inserting some asserts and running through CI confirms this. There are piles of times when we take a nominally UNORM DRI format and interpret it as sRGB. > 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. > > >> Colourspaces \_o_/ >> >> > As for enums, sure, that can probably happen. GL and ISL both have >> enums >> > for colorspace that we could re-use. >> >> Yes, having too few format tokens is not a problem we have. We seem to >> have about as many of those as we have things called 'DRI2'. >> > > Heh >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev