Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
> That said, the suggestion to use command streams for the overlay doesn't > make much sense to me. If that was a good idea, why aren't we doing > modesetting that way? Modesetting on nvidia g80+ is done through a command stream, so it isn't an entirely crazy idea. Maarten. -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/2 Michel Dänzer : > On Wed, 2009-09-02 at 08:24 +0200, Daniel Vetter wrote: >> >> btw: intel hw has some nice support for executing untrusted batchbuffers, >> so no monsterous checker/relocater/munger already present. > > The radeon CS checker goes far beyond what the Intel hardware provides > (and can provide, as e.g. it doesn't know the properties of buffer > objects). Whereas on the Thinkpad with a GM45, Mesa driver bugs still > result in GPU lockups (with a reboot being the only remedy) too often, > on the PowerBook the radeon CS checker usually catches them and > sometimes even helps find and fix the bug. > > > That said, the suggestion to use command streams for the overlay doesn't > make much sense to me. If that was a good idea, why aren't we doing > modesetting that way? Why are we doing 2D/3D accel with command buffers from userspace? I can see arguments either way for the overlay. On the one hand, there is a lot of state setup (scaling, csc transforms, lots of attributes, etc.) which would seem to want to live in the accel driver. On the other hand, use of the overlay impacts the setup of the display fifos, supported modes, and memory controller so at least some of it would be better in the kernel. To me, at least on radeon hw, userspace seems like a better fit, but that may not always be the case with other hardware. Alex -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Wed, 2009-09-02 at 08:24 +0200, Daniel Vetter wrote: > > btw: intel hw has some nice support for executing untrusted batchbuffers, > so no monsterous checker/relocater/munger already present. The radeon CS checker goes far beyond what the Intel hardware provides (and can provide, as e.g. it doesn't know the properties of buffer objects). Whereas on the Thinkpad with a GM45, Mesa driver bugs still result in GPU lockups (with a reboot being the only remedy) too often, on the PowerBook the radeon CS checker usually catches them and sometimes even helps find and fix the bug. That said, the suggestion to use command streams for the overlay doesn't make much sense to me. If that was a good idea, why aren't we doing modesetting that way? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Wed, Sep 02, 2009 at 10:18:36AM +0200, Thomas Hellström wrote: > > ... > >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. Yep, you're right. The intel driver just does not use this and sets stride values that do not fullfill the hw requirements. [Sidenote: Xv still often confuses me because only a very tiny part is actually used by modern applications. So I tend to sometimes overlook important things]. Still, there are other isssues that force intel to (unnecessarily, IMHO) copy the video frame. For reference and to make sure a future generic api supports these cases (besides the obvious stuff like pixel layout, alignment, strides which seems all to be handled by Xv): * crtc rotation. Especially painful when the vertical and horizontal UV subsampling frequencies are not equal. * the sw video decoder doesn't render into approprate memory (bo suitable for mapping into the GART/doing DMA/whater that's efficient). > > ... > >Fine. I'll just push this then as a device ioctl to bring usable video on > >8xx to kms. > > OK, > Thanks, > > Thomas Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
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 > > > 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 an
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, Sep 01, 2009 at 10:01:24PM -0700, Corbin Simpson wrote: > Then have an Intel-specific bit of code. Do a batchbuffer > checker/relocator/munger; we've got one for Radeons, and I'm sure you > guys need to do something similar for relocating BOs. That's actually what I originally wanted to do. But you have to do so many checks of the parameters, it's unfunny. And the magic dance to do state changes on the overlay hw (somethings needs changing crtc output and reverting it afterwards) is also quite complicated. So I wouldn't really be able to drop that much code, if anything at all. And instead I'd have an interface in command buffer submission that looks an awfull lot like an very special purpose ioctl in disguise. So I went down that road and created a _real_ ioctl with well-defined semantics. > ~ C. Yours, Daniel btw: intel hw has some nice support for executing untrusted batchbuffers, so no monsterous checker/relocater/munger already present. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: 079 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On 09/01/2009 02:06 PM, Daniel Vetter wrote: > On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote: >> I'm failing to see why we need an overlay ioctl at all. You end up >> pulling a relatively large amount of state setup into the drm. Why >> not treat the overlay like EXA or textured video or 3D? The overlay >> regs are pipelined on most chips so you can program them from command >> buffers. Just convert the overlay code in the ddx to use gem/ttm and >> build an appropriate command buffer or in the case of gallium add >> overlay support in the device specific code and use gem/ttm, etc.. >> You could even use it to support GL overlays. This. This so hard it hurts. > Actually that seems to be the original idea, at least there was already > some infrastructure in the driver to support this path. The problem is > that at least on intel, the overlay hw is _very_ fragile and you can > easily hang the complete chip. To prevent this a delicate dance is needed, > carefully sync with the crtc output state. > > So at least on intel, some overlay support on the kernel side is needed to > at least prevent race conditions that may hang the chip. Then have an Intel-specific bit of code. Do a batchbuffer checker/relocator/munger; we've got one for Radeons, and I'm sure you guys need to do something similar for relocating BOs. ~ C. -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote: > I'm failing to see why we need an overlay ioctl at all. You end up > pulling a relatively large amount of state setup into the drm. Why > not treat the overlay like EXA or textured video or 3D? The overlay > regs are pipelined on most chips so you can program them from command > buffers. Just convert the overlay code in the ddx to use gem/ttm and > build an appropriate command buffer or in the case of gallium add > overlay support in the device specific code and use gem/ttm, etc.. > You could even use it to support GL overlays. Actually that seems to be the original idea, at least there was already some infrastructure in the driver to support this path. The problem is that at least on intel, the overlay hw is _very_ fragile and you can easily hang the complete chip. To prevent this a delicate dance is needed, carefully sync with the crtc output state. So at least on intel, some overlay support on the kernel side is needed to at least prevent race conditions that may hang the chip. > Alex Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: 079 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
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 > >>>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: dan...@ffwll.ch Mobile: 079 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/1 Thomas Hellström : > Stephane Marchesin wrote: >> 2009/8/31 Thomas Hellström : >> >> 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? >>> >> >> Well, for example if your overlay can only do YUY16 in hardware, you >> still might want to expose YV12/I420 through Xv and do internal >> conversion. So you'd have to add format conversion somewhere in the >> stack (probably in user space though). The same happens for swapped >> components and planar/interlaced; does your hw do YV12, I420, NV12 or >> something else ? >> >> > The "hw" does YV12, YUY2 and UYVY. > > Since the user of this interface (the Xorg state tracker) is generic, > there's really no point (for us) to > have driver-specific interfaces that exposes every format that the > hardware can do. The > situation might be different, I guess, for device-specific Xorg drivers. > If we're doing this I think > we should expose perhaps a reasonable small number of common formats, > and if the hardware doesn't support any > of them, the hardware is not going to be supported. > > That might unfortunately lead to having driver-specific interfaces for > the device-specific Xorg driver and a > generic interface for the Xorg state tracker, and I'm not sure people > like that idea? > I'm failing to see why we need an overlay ioctl at all. You end up pulling a relatively large amount of state setup into the drm. Why not treat the overlay like EXA or textured video or 3D? The overlay regs are pipelined on most chips so you can program them from command buffers. Just convert the overlay code in the ddx to use gem/ttm and build an appropriate command buffer or in the case of gallium add overlay support in the device specific code and use gem/ttm, etc.. You could even use it to support GL overlays. Alex > /Thomas > >> That said, if someone achieves a generic ioctl that can do this, I >> have nothing against it. It's just that it seems to be a lot of work >> for little benefit (IMO). >> >> Stephane >> > > > > > -- > 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 > -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Stephane Marchesin skrev: > 2009/9/1 Keith Whitwell : > >> On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: >> >>> Stephane Marchesin wrote: >>> 2009/8/31 Thomas Hellström : >> 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? > > Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? >>> The "hw" does YV12, YUY2 and UYVY. >>> >>> Since the user of this interface (the Xorg state tracker) is generic, >>> there's really no point (for us) to >>> have driver-specific interfaces that exposes every format that the >>> hardware can do. The >>> situation might be different, I guess, for device-specific Xorg drivers. >>> If we're doing this I think >>> we should expose perhaps a reasonable small number of common formats, >>> and if the hardware doesn't support any >>> of them, the hardware is not going to be supported. >>> >>> That might unfortunately lead to having driver-specific interfaces for >>> the device-specific Xorg driver and a >>> generic interface for the Xorg state tracker, and I'm not sure people >>> like that idea? >>> >> I'm coming to this late, but if the only difference between hw-specific >> and hw-independent interfaces is which formats are supported, that >> surely shouldn't be too hard to abstract? Just have an enum which gets >> expanded with new format names and query for supported formats in the >> API. >> >> > > As I said, if my hw overlay only does YUY2 and I want to expose > YV12/I420 (because that's what everyone wants), I get to do the > conversion myself. Now in the old case I could do it in the driver, > but now you can either: > - remove it and players stop using the overlay altogether (because few > players will convert YV12 to YUY2 themselves) > or > - do a conversion layer between the formats which gets annoying fast > > So in the end I will still write a card-specific ioctl. > But what stops you from, following Keith's suggestion, exposing _any_ awkward format in a generic ioctl and do format conversion in user-space? The actual struct describing the format will be format-specific, and that way we neither get too restrictive nor too generic? /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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, Sep 01, 2009 at 12:10:20PM +0200, Stephane Marchesin wrote: > As I said, if my hw overlay only does YUY2 and I want to expose > YV12/I420 (because that's what everyone wants), I get to do the > conversion myself. Now in the old case I could do it in the driver, > but now you can either: > - remove it and players stop using the overlay altogether (because few > players will convert YV12 to YUY2 themselves) What kind of crappy players are you using? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/9/1 Keith Whitwell : > On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: >> Stephane Marchesin wrote: >> > 2009/8/31 Thomas Hellström : >> > >> > >> >>> 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? >> >> >> > >> > Well, for example if your overlay can only do YUY16 in hardware, you >> > still might want to expose YV12/I420 through Xv and do internal >> > conversion. So you'd have to add format conversion somewhere in the >> > stack (probably in user space though). The same happens for swapped >> > components and planar/interlaced; does your hw do YV12, I420, NV12 or >> > something else ? >> > >> > >> The "hw" does YV12, YUY2 and UYVY. >> >> Since the user of this interface (the Xorg state tracker) is generic, >> there's really no point (for us) to >> have driver-specific interfaces that exposes every format that the >> hardware can do. The >> situation might be different, I guess, for device-specific Xorg drivers. >> If we're doing this I think >> we should expose perhaps a reasonable small number of common formats, >> and if the hardware doesn't support any >> of them, the hardware is not going to be supported. >> >> That might unfortunately lead to having driver-specific interfaces for >> the device-specific Xorg driver and a >> generic interface for the Xorg state tracker, and I'm not sure people >> like that idea? > > I'm coming to this late, but if the only difference between hw-specific > and hw-independent interfaces is which formats are supported, that > surely shouldn't be too hard to abstract? Just have an enum which gets > expanded with new format names and query for supported formats in the > API. > As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) or - do a conversion layer between the formats which gets annoying fast So in the end I will still write a card-specific ioctl. Stephane -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: > Stephane Marchesin wrote: > > 2009/8/31 Thomas Hellström : > > > > > >>> 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? > >> > > > > Well, for example if your overlay can only do YUY16 in hardware, you > > still might want to expose YV12/I420 through Xv and do internal > > conversion. So you'd have to add format conversion somewhere in the > > stack (probably in user space though). The same happens for swapped > > components and planar/interlaced; does your hw do YV12, I420, NV12 or > > something else ? > > > > > The "hw" does YV12, YUY2 and UYVY. > > Since the user of this interface (the Xorg state tracker) is generic, > there's really no point (for us) to > have driver-specific interfaces that exposes every format that the > hardware can do. The > situation might be different, I guess, for device-specific Xorg drivers. > If we're doing this I think > we should expose perhaps a reasonable small number of common formats, > and if the hardware doesn't support any > of them, the hardware is not going to be supported. > > That might unfortunately lead to having driver-specific interfaces for > the device-specific Xorg driver and a > generic interface for the Xorg state tracker, and I'm not sure people > like that idea? I'm coming to this late, but if the only difference between hw-specific and hw-independent interfaces is which formats are supported, that surely shouldn't be too hard to abstract? Just have an enum which gets expanded with new format names and query for supported formats in the API. Keith -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Stephane Marchesin wrote: > 2009/8/31 Thomas Hellström : > > >>> 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? >> > > Well, for example if your overlay can only do YUY16 in hardware, you > still might want to expose YV12/I420 through Xv and do internal > conversion. So you'd have to add format conversion somewhere in the > stack (probably in user space though). The same happens for swapped > components and planar/interlaced; does your hw do YV12, I420, NV12 or > something else ? > > The "hw" does YV12, YUY2 and UYVY. Since the user of this interface (the Xorg state tracker) is generic, there's really no point (for us) to have driver-specific interfaces that exposes every format that the hardware can do. The situation might be different, I guess, for device-specific Xorg drivers. If we're doing this I think we should expose perhaps a reasonable small number of common formats, and if the hardware doesn't support any of them, the hardware is not going to be supported. That might unfortunately lead to having driver-specific interfaces for the device-specific Xorg driver and a generic interface for the Xorg state tracker, and I'm not sure people like that idea? /Thomas > That said, if someone achieves a generic ioctl that can do this, I > have nothing against it. It's just that it seems to be a lot of work > for little benefit (IMO). > > Stephane > -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/8/31 Thomas Hellström : >> 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? Well, for example if your overlay can only do YUY16 in hardware, you still might want to expose YV12/I420 through Xv and do internal conversion. So you'd have to add format conversion somewhere in the stack (probably in user space though). The same happens for swapped components and planar/interlaced; does your hw do YV12, I420, NV12 or something else ? That said, if someone achieves a generic ioctl that can do this, I have nothing against it. It's just that it seems to be a lot of work for little benefit (IMO). Stephane -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Daniel Vetter wrote: > On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote: > >> 2009/8/31 Thomas Hellström : >> >>> Daniel Vetter wrote: >>> >>> ... >>> In conclusion I don't think a common ioctl is worth it. But sharing some code and infrastructure on the kernel side is certainly possible, if someone implements overlay support for another chipset. But I don't really count on that, because at least radeon has textured video for all it's chips. >>> I understand your concerns about the new X architecture where everything >>> is composited, and I admit I haven't looked through your patch in detail. >>> >>> However, >>> we'll _probably_ need to add overlay support to the Xorg gallium + KMS >>> state-tracker shortly, and if so, with that a generic KMS interface that >>> is sufficient to implement a simple Xv overlay adaptor with KMS. >>> > > 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. 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. > >>> 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? > 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. > In short I think it's best to do the impedance matching in userspace. We > would need something there anyway to match the various video APIs onto the > kernel model. > > Yours, Daniel > > 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. 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Mon, Aug 31, 2009 at 01:57:55PM +0200, Thomas Hellström wrote: > Daniel Vetter wrote: > > ... > > In conclusion I don't think a common ioctl is worth it. But sharing some > > code and infrastructure on the kernel side is certainly possible, if > > someone implements overlay support for another chipset. But I don't really > > count on that, because at least radeon has textured video for all it's > > chips. > > > I understand your concerns about the new X architecture where everything > is composited, and I admit I haven't looked through your patch in detail. > > However, > we'll _probably_ need to add overlay support to the Xorg gallium + KMS > state-tracker shortly, and if so, with that a generic KMS interface that > is sufficient to implement a simple Xv overlay adaptor with KMS. > > 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. DirectFB has a fairly nice abstraction for this stuff (layers). You can look there for inspiration. BTW DirectFB uses the same abstraction even for CRTCs which is nice. I haven't really looked at kms yet but it seems to me that if it is too heavily based on the CRTC concept it might not be able to expose the full capabilities of hardware that doesn't really have CRTCs (eg. TI OMAP2/3). -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
2009/8/31 Thomas Hellström : > Daniel Vetter wrote: > > ... >> In conclusion I don't think a common ioctl is worth it. But sharing some >> code and infrastructure on the kernel side is certainly possible, if >> someone implements overlay support for another chipset. But I don't really >> count on that, because at least radeon has textured video for all it's >> chips. >> > I understand your concerns about the new X architecture where everything > is composited, and I admit I haven't looked through your patch in detail. > > However, > we'll _probably_ need to add overlay support to the Xorg gallium + KMS > state-tracker shortly, and if so, with that a generic KMS interface that > is sufficient to implement a simple Xv overlay adaptor with KMS. > > 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 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote: > 2009/8/31 Thomas Hellström : > > Daniel Vetter wrote: > > > > ... > >> In conclusion I don't think a common ioctl is worth it. But sharing some > >> code and infrastructure on the kernel side is certainly possible, if > >> someone implements overlay support for another chipset. But I don't really > >> count on that, because at least radeon has textured video for all it's > >> chips. > >> > > I understand your concerns about the new X architecture where everything > > is composited, and I admit I haven't looked through your patch in detail. > > > > However, > > we'll _probably_ need to add overlay support to the Xorg gallium + KMS > > state-tracker shortly, and if so, with that a generic KMS interface that > > is sufficient to implement a simple Xv overlay adaptor with KMS. Is this some new (embedded) hw support your working on (that supports gallium), Thomas? Or why do you think gallium needs overlay support? > > 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. 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. In short I think it's best to do the impedance matching in userspace. We would need something there anyway to match the various video APIs onto the kernel model. Yours, Daniel btw: I don't think we can sketch out a common interface before we have a second implementation to go pattern hunting. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Daniel Vetter wrote: ... > In conclusion I don't think a common ioctl is worth it. But sharing some > code and infrastructure on the kernel side is certainly possible, if > someone implements overlay support for another chipset. But I don't really > count on that, because at least radeon has textured video for all it's > chips. > I understand your concerns about the new X architecture where everything is composited, and I admit I haven't looked through your patch in detail. However, we'll _probably_ need to add overlay support to the Xorg gallium + KMS state-tracker shortly, and if so, with that a generic KMS interface that is sufficient to implement a simple Xv overlay adaptor with KMS. 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. 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Hi Thomas, On Mon, Aug 31, 2009 at 11:34:00AM +0200, Thomas Hellström wrote: > Hi, > > Is there any way we can try and put together a generic drm interface for > this instead of an Intel-specific one? I've tried to make the ioctl somewhat generic. That's the reason for the generic buffer format flags (and the corresponding mapping to/from intel overlay formats in kernel and ddx). So when the radeon devs are interested in overlay support, there shouldn't be a big problem in distilling a common ioctl interface. But I don't see the point in a generic ioctl, because there are quite a lot of hw specific restrictions (alignment, stride for all possible yuv formats, ...) which a generic userspace driver would not know. See intel_overlay_put_image in i915/intel_overlay.c for all the checks. A few of these tests are buffer format specific and can certainly be extracted and reused as helper functions, but besides that I don't see much code to share. Moreover we most likely still need a device specific ioctl to adjust color parameters (gamma, yuv->rbg mapping, ...). I also don't see any gain in adding overlay support to the generic struct drm_crtc because handling this crtc<->overlay relation is just a few lines in my code. So not many opportunities to share stuff. > Surely it will have a use for the Gallium Xorg state-tracker which is > intended to be a device-independent Xorg driver on top of KMS and > Gallium. At least for intel this does not make sense. Gallium is only supported for 915 and onwards. So is textured video. Which leaves us with 8xx class hw in need of overlay support but no way of gallium support (no shaders). Furthermore I don't think it's a good idea to spoil the shiny new X architecture with support for archaic hardware like overlays (which ruins every compositioned desktop experience). In conclusion I don't think a common ioctl is worth it. But sharing some code and infrastructure on the kernel side is certainly possible, if someone implements overlay support for another chipset. But I don't really count on that, because at least radeon has textured video for all it's chips. > /Thomas Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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
Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Daniel Vetter wrote: > Open issues: > - Flickering. But when the frame is not changed, this stabilizes > after a few seconds (at most). This is in a 855GM and a 865G, other > chipset variants are untested. > - Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately > changes in this area tend to hang the hw, so let's leave it at this > for the moment. I left some dummy functions as infrastructure. > > Changes since v1: > - fix off-by-one misconception on my side. This fixes fullscreen > playback. > > Tested-By: diego.abele...@gmail.com (on a 865G) > Signed-off-by: Daniel Vetter > --- > Hi, Is there any way we can try and put together a generic drm interface for this instead of an Intel-specific one? Surely it will have a use for the Gallium Xorg state-tracker which is intended to be a device-independent Xorg driver on top of KMS and Gallium. /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
[PATCH 6/6] [drm/i915] implement drmmode overlay support v2
Open issues: - Flickering. But when the frame is not changed, this stabilizes after a few seconds (at most). This is in a 855GM and a 865G, other chipset variants are untested. - Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately changes in this area tend to hang the hw, so let's leave it at this for the moment. I left some dummy functions as infrastructure. Changes since v1: - fix off-by-one misconception on my side. This fixes fullscreen playback. Tested-By: diego.abele...@gmail.com (on a 865G) Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_dma.c |7 + drivers/gpu/drm/i915/i915_drv.h |4 + drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_display.c | 26 +- drivers/gpu/drm/i915/intel_drv.h | 30 + drivers/gpu/drm/i915/intel_overlay.c | 1284 ++ include/drm/i915_drm.h | 71 ++ 8 files changed, 1425 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 30d6b99..d06fece 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -22,6 +22,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_fb.o \ intel_tv.o \ intel_dvo.o \ + intel_overlay.o \ dvo_ch7xxx.o \ dvo_ch7017.o \ dvo_ivch.o \ diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 50d1f78..7763967 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -777,6 +777,9 @@ static int i915_getparam(struct drm_device *dev, void *data, case I915_PARAM_NUM_FENCES_AVAIL: value = dev_priv->num_fence_regs - dev_priv->fence_reg_start; break; + case I915_PARAM_HAS_OVERLAY: + value = dev_priv->overlay ? 1 : 0; + break; default: DRM_DEBUG_DRIVER(I915_DRV, "Unknown parameter %d\n", param->param); @@ -1310,6 +1313,8 @@ int i915_driver_unload(struct drm_device *dev) mutex_unlock(&dev->struct_mutex); drm_mm_takedown(&dev_priv->vram); i915_gem_lastclose(dev); + + intel_cleanup_overlay(dev); } kfree(dev->dev_private); @@ -1416,6 +1421,8 @@ struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, 0), DRM_IOCTL_DEF(DRM_I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 0), DRM_IOCTL_DEF(DRM_I915_GET_PIPE_FROM_CRTC_ID, intel_get_pipe_from_crtc_id, 0), + DRM_IOCTL_DEF(DRM_I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image, DRM_MASTER|DRM_CONTROL_ALLOW), + DRM_IOCTL_DEF(DRM_I915_OVERLAY_ATTRS, intel_overlay_attrs, DRM_MASTER|DRM_CONTROL_ALLOW), }; int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2d79ede..19dd7c3 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -149,6 +149,7 @@ struct drm_i915_error_state { struct timeval time; }; +struct intel_overlay; typedef struct drm_i915_private { struct drm_device *dev; @@ -206,6 +207,9 @@ typedef struct drm_i915_private { struct intel_opregion opregion; + /* overlay */ + struct intel_overlay *overlay; + /* LVDS info */ int backlight_duty_cycle; /* restore backlight to this value */ bool panel_wants_dither; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2955083..7bb6e88 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -116,6 +116,7 @@ #define MI_NOOPMI_INSTR(0, 0) #define MI_USER_INTERRUPT MI_INSTR(0x02, 0) #define MI_WAIT_FOR_EVENT MI_INSTR(0x03, 0) +#define MI_WAIT_FOR_OVERLAY_FLIP (1<<16) #define MI_WAIT_FOR_PLANE_B_FLIP (1<<6) #define MI_WAIT_FOR_PLANE_A_FLIP (1<<2) #define MI_WAIT_FOR_PLANE_A_SCANLINES (1<<1) @@ -127,6 +128,10 @@ #define MI_END_SCENE (1 << 4) /* flush binner and incr scene count */ #define MI_BATCH_BUFFER_ENDMI_INSTR(0x0a, 0) #define MI_REPORT_HEAD MI_INSTR(0x07, 0) +#define MI_OVERLAY_FLIPMI_INSTR(0x11,0) +#define MI_OVERLAY_CONTINUE (0x0<<21) +#define MI_OVERLAY_ON(0x1<<21) +#define MI_OVERLAY_OFF (0x2<<21) #define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0) #define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1) #define MI_MEM_VIRTUAL (1 << 22) /* 965+ only */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index cb709b8..d2ddcbd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display