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
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
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
2009/9/2 Michel Dänzer mic...@daenzer.net: 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
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
Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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, 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
Stephane Marchesin skrev: 2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
2009/9/1 Thomas Hellström tho...@shipmail.org: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
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 /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: 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
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 daniel.vet...@ffwll.ch --- 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
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: ... 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
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
2009/8/31 Thomas Hellström tho...@shipmail.org: 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 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
Daniel Vetter wrote: On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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
2009/8/31 Thomas Hellström tho...@shipmail.org: 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
