[Mesa-dev] [PATCH] __DRIimage: Add formats with implied swizzling

Kristian Høgsberg krh at bitplanet.net
Wed Jul 18 12:48:44 PDT 2012

On Wed, Jul 18, 2012 at 12:02 PM, Eric Anholt <eric at anholt.net> wrote:
> Kristian Høgsberg <krh at bitplanet.net> writes:
>> When we sample U and V from YUYV buffers, U and V ends up in G and A
>> in the shader.  Instead of pushing this to the application, just swizzle
>> U and V to R and G and set B to 0 and A to 1.
> Those fields are controlled by EXT_texture_swizzle.  We probably
> shouldn't mess with the defaults of GL state.

I did this with GLES2 in mind and there's no swizzling control in
GLES2 or any GLES2 extensions.  But of course, it's possible to use
EGL and full GL in which case we'll be fighting over the state with
the application.

> Other nastiness where we're hiding the actual format from the user for
> GL's depth sampling has been done with a switch in
> brw_populate_sampler_prog_key_data().  But if we're actually just doing
> RGBA underneath, it seems like suggesting to people that they sample
> RGBA and swizzle in their shaders would avoid code and be reasonable.
> It's what GL resolved for the depth sampling, we just still support GL
> 2.0.

Yeah, I saw the code in brw_populate_sampler_prog_key_data(), which is
what prompted this patch.  We aren't just doing RGBA underneath
though, it's YUYV.  We want to sample the U and V components in this
case, and they end up in G and A in the shader without the swizzle.
Without this patch I have to communicate that to the application
(weston) (as opposed to just "you'll be sampling U and V" with the
implication that they map to R and G).  The application has to use
different shaders for when U and V ends up in R and G (the case for
NV12) and for when they end up in G and A (for YUYV buffers), since
there's no way to swizzle that away in GLES2.  That's what we have now
in mesa (and in weston) and we can just leave it that way.  Or just go
to GL_OES_EGL_image_external and the magic samplerExternalOES.


More information about the mesa-dev mailing list