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

[Younes Manton]

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.