libdrm issues blocking accelerated indirect GL

[Adam Jackson]

The goal: Load DRI drivers from the server's libglx, rather than the 
software-based libGLcore.

Currently there are four server-side modules: dri, drm, glx, and GLcore.  
There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.  
'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally 
imported into X as hw/xfree86/os-support/$(uname)/drm.  libdrm is identical 
on both sides, modulo wrapping some things like malloc to use either the Mesa 
or X version.

The problem here is, libdrm is linked into each DRI driver, as well as loaded 
dynamically by the server.  If we want the server to be able to load DRI 
drivers, then we need to make sure the two instances of libdrm don't 
conflict.  So we have options here.

- Option 1: Move libdrm from the DRI drivers into libGL (static linkage)
Pros: Minimal server impact.
Cons: Breaks libGL/driver ABI.  DRM changes now require upgrading two
      components.  Increases libGL footprint.

- Option 2: Move libdrm from the DRI drivers into libGL (dynamic linkage)
Pros: Minimal server impact.  New libdrm could be shared between client and
      server.
Cons: Breaks libGL/driver ABI.  Creates new DSO with associated API management
      hassles.  DRM changes require upgrading two components (though not
      libGL [1]).

- Option 3: Move libdrm from the DRI drivers into libGL (dlopen linkage)
Pros: Minimal server impact.  New libdrm could be shared between client and
      server.  With a little cleverness [2], doesn't break the libGL/driver
      ABI, so drivers and libGLs from both sides of the change can be
      mixed freely.
Cons: Creates new DSO.  DRM changes require upgrading two components (though
      not libGL).

- Option 4: Link libdrm into the DRI drivers dynamically instead.
Pros: Doesn't change libGL/driver ABI.  
Cons: Requires server control over runtime link path, sketchy.  DDX also calls
      into libdrm, so DRI driver would need to be loaded into the server quite
      early.  Creates a new unshared DSO.

- Option 5: Load libdrm into the DRI drivers via dlopen
Pros: Doesn't change libGL/driver ABI.  Server can continue to use own copy of
      libdrm, maybe [3].
Cons: Drivers have to be extended to not dlopen libdrm if either the symbols
      already exist or if the driver somehow knows it's being loaded by the
      server, which is kind of hackish.  Creates a new unshared DSO.

- Option 6: Start linking the DRI drivers -Bsymbolic and (optionally) hide
            their libdrm symbols using gcc visibility attributes.
Pros: Minimal server impact.
Cons: Relies on toolchain features that may not exist.  Still requires a copy
      of libdrm in the server source.  libdrm needs more hacks to behave
      differently depending on whether it's built in server, since DDX still
      needs to call into drm.

[1] - In a perfect world, the libGL in Mesa would be sufficient to load _any_ 
DRI-based driver, closed or open.  I really want to see this happen, so 
vendors only need to supply the pieces that are relevent to their hardware.

[2] - libGL dlopen's the driver RTLD_LAZY, attempts to dlsym it for, say, 
drmLock.  If successful, the driver has libdrm linked into it, and we proceed 
the way we do now.  If the dlsym fails, dlclose the driver, dlopen libdrm 
RTLD_NOW|RTLD_GLOBAL, dlopen DRI driver RTLD_NOW|RTLD_GLOBAL, go.

[3] - Depending on how libdrm is loaded into the server.  If bound in at link 
time, sure.  If loaded at runtime, then the DRI driver will only pick up the 
symbols from the server's libdrm if the server is using dlloader, for the 
usual crosscalling reasons.

Personally I lean towards 2 or 3.  The nice bit about making libdrm a real DSO 
is that it removes the need to have the libdrm source around when building 
the -dri targets in Mesa, or when building the server; you just need to have 
built it already.  You have to handle libdrm versioning anyway.  We may as 
well think about it explicitly.  Fortunately libdrm is pretty static, the 
last change that even might have broken the ABI was 14 months ago.

Any thoughts?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041230/b2d81799/attachment.pgp>