[Mesa-dev] [RFC 12/13] i965: support for YUV formatted external textures

Ian Romanick idr at freedesktop.org
Wed Feb 27 17:15:11 PST 2013


On 02/27/2013 03:41 PM, Kristian Høgsberg wrote:
> On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi
> <topi.pohjolainen at intel.com> wrote:
>> On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote:
>>> On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
>>> <topi.pohjolainen at intel.com> wrote:
>>>> Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader
>>>> program with instructions that sample the separate Y- and U/V-planes
>>>> and convert the YUV to RGB as specified by ITU-R BT.601. Packed
>>>> formats are handled through the normal paths.
>>>
>>> I didn't read the entire patch series yet, but this doesn't sound
>>> right.  You can't handle packed (YUYV) buffers through normal
>>> sampling.  If you're filtering, you end up blending the wrong
>>> components.  If you're sampling the buffer as 32 bpp, you'll blend Y
>>> components not with their neighboring pixel but the pixel one over, as
>>> each sample has two Y components.  If you sample the texture as 16bpp,
>>> you end up blending the U and V components as you sample.  The trick
>>> is to set up two textures for the same buffer and sample Y using a 16
>>> bpp texture and sample the U and V components using a 32 bpp buffer.
>>
>> Here the first two (YUV420, YVU420) have all the components in different planes
>> and I'm giving each plane its own sampling surface, and hence sampling them
>> separately as R8_UNORM. The packed UV-plane of NV12 I'm treating in turn as
>> having two channels (sampling using R8G8_UNORM). Does that make sense? I haven't
>> written support for anything more complex yet, but it is good to know your trick
>> if the need arises.
>
> Right, that works for thos formats.  The trick of using two samplers
> on the same buffer applies to YUYV buffers, ie packed format where
> each 32bit word contains two Y samples, one U and one V sample and
> corresponds to two pixels.

We have surface formats, BRW_SURFACEFORMAT_YCRCB_*, for those kinds of 
packed formats.  We use that (or used to use that) to support 
GL_MESA_ycbcr_texture.  On GEN4+ it just doesn't do the color space 
conversion.

I do like your trick, though. :)



More information about the mesa-dev mailing list