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

Kristian Høgsberg krh at bitplanet.net
Wed Feb 27 18:03:41 PST 2013


On Wed, Feb 27, 2013 at 8:15 PM, Ian Romanick <idr at freedesktop.org> wrote:
> 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 did see those in the spec and tried to get them to work, I just
never got the right result.  I didn't try very hard, but it's also not
a format that our decoders generate (intel hw).

Kristian

> I do like your trick, though. :)
>


More information about the mesa-dev mailing list