[Mesa-dev] About merging pipe-video to master

Keith Whitwell keithw at vmware.com
Tue Jul 12 08:27:25 PDT 2011

On Tue, 2011-07-12 at 11:13 -0400, Younes Manton wrote:
> 2011/7/12 Keith Whitwell <keithw at vmware.com>:
> > I'm a bit unsure about what's the best approach here, though at this
> > stage I'm happy with your approach and don't think it needs to be
> > changed before any merge.
> >
> > But speaking in general terms, individual planes map well onto 8-bit
> > single-component texture images (L8 or similar) and any hardware
> > requirements (pitch, memory pool, etc) for the individual plane could be
> > specified with a PIPE_BIND_VIDEO_BUFFER flag.
> >
> > However, it's also easy to imagine hardware having special requirements
> > about the positioning of the planes relative to one another, similar to
> > how mipmaps must be layed out in hardware-specific ways.
> >
> > If we did decide to get rid of video_buffers and integrate the concept
> > with pipe_resources, it seems like there would need to be a way to
> > specify this at resource creation - either a planar YUV format, or some
> > other marking on the resource.
> >
> > I don't have easy answers for that, and in the meantime I don't think
> > it's important enough to hold up pipe-video, which is looking now like a
> > good step forward.
> >
> > Keith
> I've considered that. The problem that brings up is what happens when
> you need to hand that planar surface over to the 3D context as a
> texture to be sampled from for color conversion. From the state
> tracker's POV you've just handed over a single texture with
> corresponding vertex attribs, texcoords, shaders, etc, but in reality
> your 3D engine will have to treat each plane as a separate texture.
> You could special-case planar textures and internally create extra
> state objs and fix up the shader, but the extra complexity buys you
> nothing except a "nicer looking" planar texture representation in the
> interface and is ugly in itself.
> Anyhow, Christian, your changes look alright to me. Again, I don't
> think this interface has to be perfect now to be acceptable.



More information about the mesa-dev mailing list