[lkml]   [2010]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git pull] drm request 3
    On Fri, 5 Mar 2010 12:21:29 +0000, Alan Cox <> 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.
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2010-03-05 20:33    [W:0.021 / U:11.040 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site