2011/7/12 Keith Whitwell <kei...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
