[Intel-gfx] [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

[Daniel Vetter]

On Mon, Aug 31, 2009 at 02:58:15PM +0200, Thomas Hellström wrote:
> > ...

> >Is this some new (embedded) hw support your working on (that supports
> >gallium), Thomas? Or why do you think gallium needs overlay support?
> 
> I must stress this is not Gallium. It's the Xorg state-tracker that uses
> Gallium for acceleration and KMS for modesetting.  We want to leverage
> that to a usable state for an application where we probably can't drop
> previous (overlay) capabilities. Textured Xv adaptors of course goes
> through Gallium, Overlay needs to go through KMS.

That's what I've ment, I've just phrased it badly.

> The other possible use I can see is for embedded devices where power
> is a big concern, but that's nothing
> we're involved in ATM. I do think, however, that overlays are going
> to live on for a while in those devices.

IMHO we need a video pipe object in gallium anyway to support all the
special power efficient hw in embedded devices. In combination with a
gallium video state tracker for a modern api this should give us awesome
video on embedded devices </wishful dreaming>

> >>>Given the fact that Xv and various virtual device overlay support
> >>>implementations exist, I assume there *must* be a way to do this
> >>>generically. Perhaps not in the interest of sharing kernel code, but in
> >>>the interest of a single user-space interface and a single user-space
> >>>implementation supporting multiple hardware drivers.
> >>I've looked at this before, and you basically end up adding something
> >>similar to the Xv API in the kernel (for handling pixel formats, size
> >>& pitch limitations, vsyncing, ...). I'm not sure it's worth it,
> >>especially since overlays are doomed. Of course overlays are faster
> >>than textured/blitter video so it's worth implementing, but I'd keep
> >>this as a device-specific ioctl.
> >>
> >>Stephane
> >
> >The problem I see with Xv-API-in-kernel is that of the various hw
> >constrains on the buffer layout. IMHO this has two solutions:
> >
> >a) complicated to communicate the constrains to userspace. This is either
> >to generic or not suitable for everything.
> 
> IIRC Xv exposes this all the way down to the user-app, as format and
> then offset into buffer + stride for each plane?

Nope, Xv has one fixed format with stride == line length. Atm, the intel
driver unconditionally copies the planes from a userspace buffer into a bo
(with correct stride, rotation applied, ...). That's also why I think Xv
is not really worth too much trouble because it hands memory pointers and
not bo's to the driver. (Which btw results in some _very_ ugly hacks to
achieve zero-copy XvMC by assuming that the pointer handed in by the
client-side libXvMC is just a GART offset ... This obviously doesn't work
with bo relocating/kms)

> >b) one fixed format. If it does not fit, just copy the stuff in the right
> >format into a new bo. This is what the intel Xv driver does at the moment.
> >I don't think this belongs into the kernel.
> 
> Agreed.  It's not a problem to implement this in a generic
> user-space driver.

As I've already said I think the way forward is gallium-video state
tracker (and not Xv). This way we can ensure that the draw module (via
shaders/software) or the hw render the frames with the right constrains
directly into bo's. This way we can omit the atm inevitable copy that the
Xv api forces upon drivers.  This should also be usable for embedded
devices with low-power overlay and dedicated video pipelines.

One small thing to keep in mind: To make this video state tracker on
gallium thing work we probably need to extend the DRI2 proto such that X
can work as an arbiter for the overlay.

> > ...

> >btw: I don't think we can sketch out a common interface before we have a second
> >implementation to go pattern hunting.
> OK. We're probably some time away on this.

Fine. I'll just push this then as a device ioctl to bring usable video on
8xx to kms.

> Thanks,
> /Thomas

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: 079 365 57 48