| Message ID | 1355871094-5502-1-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> Aren't all the yuv formats we support packet planar? So I think we should be able to support source offsets, as long as x is even ... Probably not worth the bother though. -Daniel
On Tue, 18 Dec 2012 23:57:05 +0100, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> > > Aren't all the yuv formats we support packet planar? So I think we > should be able to support source offsets, as long as x is even ... > Probably not worth the bother though. Didn't seem to work, so I opted to just avoid the issue. -Chris
On Tue, 18 Dec 2012 23:03:02 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, 18 Dec 2012 23:57:05 +0100, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> > > > > Aren't all the yuv formats we support packet planar? So I think we > > should be able to support source offsets, as long as x is even ... > > Probably not worth the bother though. Ok, double-checked and they are using a packed format, so it should be possible given the single linear offset and a co-operative userspace to pass in valid x/y offsets. I'm no longer trying to use this in the ddx, so you can leave it in until someone with a little more clue feels like tackling it. -Chris
On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote: > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> 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. > So I think we > should be able to support source offsets, as long as x is even ... > Probably not worth the bother though. The gen4+ plane hardware sucks. The gen3 video overlay handled sub-pixel precision very nicely. And we really want to handle source offsets, otherwise pan&scan isn't possible.
On Wed, Dec 19, 2012 at 12:03:09PM +0000, Chris Wilson wrote: > On Wed, 19 Dec 2012 13:56:12 +0200, Ville Syrjälä <ville.syrjala@linux.intel.com> 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 <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> > > > > 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. Ah yeah it's the fb->bits_per_pixel problem. I though I submitted the change to drm_format_plane_cpp() from my atomic branch, but I can't see it in the upstream code. Either I forgot it, or it never got applied.
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 97866c2..3e05d79 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -497,6 +497,19 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, return -EINVAL; } + if (obj->tiling_mode == I915_TILING_NONE && (src_x | src_y)) { + /* Source offsets are not supported with subsampled formats + * if using a linear framebuffer. + */ + switch (fb->pixel_format) { + case DRM_FORMAT_YUYV: + case DRM_FORMAT_YVYU: + case DRM_FORMAT_UYVY: + case DRM_FORMAT_VYUY: + return -EINVAL; + } + } + /* * Reject any attempt to display video outside the visible area. * The caller must handle this by adjusting source offset and size.
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 <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_sprite.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)