[PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Chris Wilson]

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(+)

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.
-- 
1.7.10.4

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Chris Wilson]

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

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Chris Wilson]

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

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Chris Wilson]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel OTC