On Wed, 19 Dec 2012 13:56:12 +0200, Ville Syrjälä <[email protected]> wrote: > On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote: > > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <[email protected]> > > wrote: > > > As we can only pass in the base address of the first plane, we can not > > > control the offset into the subsampled chroma planes. This means that we > > > cannot support a source offset into a YUV* linear framebuffer. However, > > > for tiled framebuffers we can tell the hardware which pixels to read > > > from. So if we see a source offset into a linear YUV framebuffer, report > > > the invalid value back to userspace. > > > > > > Signed-off-by: Chris Wilson <[email protected]> > > I can't see the original mail with the patch, where did it go? > > > Aren't all the yuv formats we support packet planar? > > No idea what packet planar means. All we currently support are packed > formats. The problem is that our code doesn't handle fb->offsets[]. > > If you're talking about src_x,src_y then those do work, at least on my > atomic branch. I don't remember changing the src_x/src_y related code > that much (apart from adding proper clipping), so I'm fairly sure they > should work in the upstream code as well.
They only work with a tiled source, as far as my investigation into the current code revealed. -Chris -- Chris Wilson, Intel Open Source Technology Centre
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
