On Wed, Feb 27, 2013 at 8:15 PM, Ian Romanick <i...@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.pohjolai...@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.pohjolai...@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. :) > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
