Daniel Vetter skrev: > 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.
This is perhaps a little out of scope, but I'm pretty sure Xv sets up the HW needed stride of Xv images and pushes that to the client, and if the client doesn't adhere to it, that's a bug in the client. That's done in queryImageAttributes(). It's used, for example in the unichrome / openchrome drivers to make it possible to use the PCI DMA engine (which has stride limitations) for image uploads. IIRC it's in the Xv docs as well, but it was a couple of years ago I last looked at this. > 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) > No, it obviously doesn't. But XvMC (if it lives on) has the means of having the server creating the surfaces (and bos) and communicate all sorts of surface info down to the XvMC client library. >>> 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. > I haven't really thought about this, and there might be ways to have certain subsets of the overlay functionality in a gallium interface, but it's important that we know the constraints and possibilities. *) Overlay setup requires pinning overlay scanout buffers and memory bandwidth allocation / checks / conflict resolving. That can only be done by a DRM master, but I see you have commented on that below. *) Some hardware allows binding system memory directly to the GPU, in what used to be referred to as "User bos". This means that the Xv SW copy can be avoided in many cases and replaced by a GPU blit or DMA operation. > 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. > Yes, and it's at least for this we need the generic KMS bits. > Fine. I'll just push this then as a device ioctl to bring usable video on > 8xx to kms. > > OK, Thanks, Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
