On Fri, 5 Mar 2010 12:21:29 +0000, Alan Cox <a...@lxorguk.ukuu.org.uk> wrote: > Serious discussion point perhaps should be: is the libdrm so close to the > kernel it ought to be in the same git tree ? Alternatively does it need > to be easier to have multiple Nouveau libdrms autoselected according to > the kernel side versioning. ELF library versioning is not rocket science > and both the old and new libraries exist and can be installed so all the > bits are present except for the wrapper to load the right sublibrary yes ?
That *would* make versioning impossible. To make the difficulty of improving ABI at the moment concrete, I just got done merging the patches for execbuf2 in userland and enabling i915 texture tiling. This was a 3% performance win in one test I was looking at, and 1% in another -- less than hoped, but important nonetheless (there are other cases that should see 30% or so wins hopefully). The patches got written back in July, and revved several times as they broke various combinations of compatibility. At the point that I merged eb2 to the kernel for 2.6.33, it wasn't *really* tested -- the userland side was broken all to hell it looked like, but at least it wasn't regressing execbuf1 any more, right? I spent this week getting userland working, including a new libdrm release (already obsolete because a bug in the libdrm violated what the ABI between libdrm <-> msea was supposed to be). So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying "dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow." This is not that bad for Intel folks. We're paid to hack on it, and can justify spending ridiculous amounts of time for small wins. I actually enjoy this. Right now all the userland -- whether it's Mesa, xf86-video-intel, libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand that new flag to libdrm as if the kernel supported the new interface. Inside libdrm, it looks at the kernel version and uses the new interface or old as appropriate. The ugly versioning stuff stays in one easy-to-review 5kloc component, and the complicated 50kloc driver components get to pretend they have a fancy new kernel. But if libdrm's in the kernel, all those userland components no longer get to rely on the version of libdrm, because distros will ship whatever's with the kernel they're using and our userland does have to work on (relatively recent) distros. Each of those userland components would have to grow a compatibility layer to work with whatever kernel libdrm is available, passing the flag in the new API or using the old API. Userland would even buggier for having to replicate all that logic everywhere, and we probably wouldn't have execbuf2 landed yet. Well, OK. What I'd really do instead is make the kernel libdrm be a thin ioctl wrapper, and build a librealdrm that does what libdrm does today. But I don't think that's what you were suggesting.
pgp21kB5PwxVU.pgp
Description: PGP signature
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
