RE: [Linaro-mm-sig] New xf86-video-armsoc DDX driver
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: 21 May 2012 10:04 To: Dave Airlie Cc: Tom Cooksey; linaro-mm-...@lists.linaro.org; xorg- de...@lists.x.org; dri-de...@lists.freedesktop.org Subject: Re: [Linaro-mm-sig] New xf86-video-armsoc DDX driver On Mon, May 21, 2012 at 09:55:06AM +0100, Dave Airlie wrote: * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. Or go the intel glamour route and stitch together a somewhat generic 2d accel code on top of GL. That should give you reasonable (albeit likely not stellar) X render performance. -Daniel I'm not sure that would perform well on a tile-based deferred renderer like Mali. To perform well, we need to gather an entire frame's worth of rendering/draw-calls before passing them to the GPU to render. I believe this is not the typical use-case of EXA? How much of the framebuffer is re-drawn between flushes? Cheers, Tom ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Linaro-mm-sig] New xf86-video-armsoc DDX driver
On Mon, May 21, 2012 at 09:55:06AM +0100, Dave Airlie wrote: * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. Or go the intel glamour route and stitch together a somewhat generic 2d accel code on top of GL. That should give you reasonable (albeit likely not stellar) X render performance. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
New xf86-video-armsoc DDX driver
Hi All, For the last few months we (ARM MPD... The Mali guys) have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via KMS. The KMS driver also allocates both scan-out and pixmap/back buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. When returning buffers to DRI clients, the x-server uses flink to get a global handle to a buffer which it passes back to the DRI client (in our case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME ioctls to export the GEM buffer it received from the x-server to a dma_buf fd. This fd is then passed into the T6xx kernel driver via our own job dispatch user/kernel API (we're not using DRM for driving the GPU, only the display controller). Note: ARM doesn't generally provide the display controller IP block, so this is really for our customers/Linaro to develop, though we do have something hacked up for ARM's own PL111 display controller on our Versatile Express development platform which we'll be open sourcing/up-streaming asap via Linaro. We believe most ARM SoCs are likely to work the same way, at least those with 3rd-party GPU IP blocks/drivers (so everyone except Qualcomm nVidia). As mentioned, this is certainly how the OMAP integration works. As such, we've taken the OMAP DDX driver Rob Clark wrote and hacked on it to make it work for Mali. The patch is actually relatively small, which is not really too surprising as all the driver is doing is allocating buffers and managing a display controller via a device-agnostic interface (KMS). All the device-specific code is kept in the DRM driver and the client GLES/EGL library. Given that the DDX driver doesn't contain any device-specific code, we're going to take the OMAP DDX as a baseline and try and make it more generic. Our immediate goals are to make it work on our own Versatile Express development platform and on Samsung's Exynos 5250 SoC, however our hope is to have a single DDX driver which can cover OMAP, Exynos, ST-E's Nova/Thor platforms and probably others too. It's even been suggested it could work with Mesa's sw backend(?). Anyway, the DDX is very much a work-in-progress and is still heavily branded OMAP, even though it's working (almost) perfectly on VExpress Exynos too (re-branding isn't too high-up our priority list at the moment). We are actively developing this driver and will be doing so in a public git repository hosted by Linaro. We will not be maintaining any private repository behind ARM's firewall or anything like that - you'll see what we see. The first patches have now been pushed, so if anyone's interested in seeing what we have so far or wants to track development, the tree is here: http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa ry Note: When we originally spoke to Rob Clark about this, he suggested we take the already-generic xf86-video-modesetting and just add the dri2 code to it. This is indeed how we started out, however as we progressed it became clear that the majority of the code we wanted was in the omap driver and were having to work fairly hard to keep some of the original modesetting code. This is why we've now changed tactic and just forked the OMAP driver, something Rob is more than happy for us to do. One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In the short-term, we will simply create a branch off of the generic master for each SoC and add 2D hardware support there. We do however want a more permanent solution which doesn't need a separate branch per SoC. Some of the suggested solutions are: * Add a new generic DRM ioctl API for larger 2D operations (I would imagine small blits/blends would be done in SW). * Use SW rendering for everything other than solid blits and use v4l2's blitting API for those (importing/exporting buffers to be blitted using dma_buf). The theory here is that most UIs are rendered with GLES and so you only need 2D hardware for blits. I think we'll prototype this approach on Exynos. * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). We are hoping someone might have some advice suggestions on how to proceed with regards to 2D. We're also very interested in any feedback, both on the DDX driver specifically and on the approach we're taking in general. Cheers, Tom ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: New xf86-video-armsoc DDX driver
For the last few months we (ARM MPD... The Mali guys) have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via KMS. The KMS driver also allocates both scan-out and pixmap/back buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. When returning buffers to DRI clients, the x-server uses flink to get a global handle to a buffer which it passes back to the DRI client (in our case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME ioctls to export the GEM buffer it received from the x-server to a dma_buf fd. This fd is then passed into the T6xx kernel driver via our own job dispatch user/kernel API (we're not using DRM for driving the GPU, only the display controller). So using dumb in this was is probably a bit of an abuse, since dumb is defined to provide buffers not to be used for acceleration hw. Since when we allocate dumb buffers, we can't know what special hw layouts are required (tiling etc) for optimal performance for accel. The logic to work that out is rarely generic. http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa ry Note: When we originally spoke to Rob Clark about this, he suggested we take the already-generic xf86-video-modesetting and just add the dri2 code to it. This is indeed how we started out, however as we progressed it became clear that the majority of the code we wanted was in the omap driver and were having to work fairly hard to keep some of the original modesetting code. This is why we've now changed tactic and just forked the OMAP driver, something Rob is more than happy for us to do. It does seem like porting to -modesetting, and maybe cleaning up modesetting if its needs it. The modesetting driver is pretty much just a make it work port of the radeon/nouveau/intel code shared code. One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In the short-term, we will simply create a branch off of the generic master for each SoC and add 2D hardware support there. We do however want a more permanent solution which doesn't need a separate branch per SoC. Some of the suggested solutions are: * Add a new generic DRM ioctl API for larger 2D operations (I would imagine small blits/blends would be done in SW). Not going to happen, again the hw isn't generic in this area, some hw requires 3D engines to do 2D ops etc. The limitations on some hw with overlaps etc, and finally it breaks the rule about generic ioctls for acceleration operations. * Use SW rendering for everything other than solid blits and use v4l2's blitting API for those (importing/exporting buffers to be blitted using dma_buf). The theory here is that most UIs are rendered with GLES and so you only need 2D hardware for blits. I think we'll prototype this approach on Exynos. Seems a bit over the top, * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. I haven't time this week to review the code, but I'll try and take a look when time permits. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
