On Sat, Nov 24, 2012 at 11:54:32PM +0100, Lucas Stach wrote: > Am Samstag, den 24.11.2012, 22:09 +0100 schrieb Thierry Reding: > > Hi, > > > > With tegra-drm going into Linux 3.8 and NVIDIA posting initial patches > > for 2D acceleration on top of it, I've been looking at the various ways > > how this can best be leveraged. > > > > The most obvious choice would be to start work on an xf86-video-tegra > > driver that uses the code currently in the works to implement the EXA > > callbacks that allow some of the rendering to be offloaded to the GPU. > > The way I would go about this is to fork xf86-video-modesetting, do some > > rebranding and add the various bits required to offload rendering. > > > As much as I dislike to say this, but forking the modesetting driver to > bring in the Tegra specific 2D accel might be the best way to go for > now. Especially looking at the very limited resources available to > tegradrm development and NVIDIAs expressed desire to do as few changes > as possible to their downstream work. So true. But I'm not sure if it's a good excuse to not do things the right way, even if it ends up being more work. If the general situation can be improved then I think it's worth the effort. > > However, that has all the usual drawbacks of a fork so I thought maybe > > it would be better to write some code to xf86-video-modesetting to add > > GPU-specific acceleration on top. Such code could be leveraged by other > > drivers as well and all of them could share a common base for the > > functionality provided through the standard DRM IOCTLs. > > > We don't have any standard DRM IOCTLs for doing acceleration today. The > single fact that we are stitching together command streams in userspace > for execution by the GPU renders a common interface unusable. We don't > even have a common interface to allocate GPU resources suitable for > acceleration: the dumb IOCTLs are only guaranteed to give you a buffer > the display engine can scan out from, nothing in there let's you set up > more fancy things like tiling etc, which might be needed to operate on > the buffer with other engines in some way. With the common base that could be shared I meant all the modesetting code and framebuffer setup that xf86-video-modesetting already does. I've been wanting to add support for planes as well, which comes with another set of standard IOCTLs in DRM. Rewriting all of that in different drivers doesn't seem very desirable to me and sounds like a lot of wasted effort. And that's not couting the maintenance burden to keep up with the latest changes in the generic modesetting driver. > > That approach has some disadvantages of its own, like the potential > > bloat if many GPUs do the same. It would also be a bit of a step back > > to the old monolithic days of X. > > > For some thoughts about how a unified accelerated driver for various > hardware devices could be done I would like to point at my presentation > at this years XDC. > However doing this right might prove as a major task, so as I already > said it might be more worthwhile to just stuff the Tegra specific bits > into a fork of the modesetting driver. One major advantage of putting this into the modesetting driver is that as more hardware support is added common patterns might emerge and make it easier to refactor things into generic code. Thierry
Attachment:
pgpIZgbxkWijW.pgp
Description: PGP signature
