libdrm issues blocking accelerated indirect GL

[Felix Kühling]

Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> 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.

I have a seventh option for you. Feel free to flame me if it sounds
stupid ...

- Option 7: Run the GLX server as a separate process forked by the
Xserver. This way you get rid of the problem with the same library
linked into the same process multiple times.

Pros: No existing ABIs need to be changed. It would also improve the
responsiveness of the Xserver when expensive indirect rendering
operations are performed (for instance software fallbacks).

Cons: GLX protocol goes through the same channel as X protocol. So doing
GLX in a separate process would involve forwarding GLX protocol from the
Xserver to the real GLX server process in some way. Not sure how much
overhead in time and code complexity that would introduce.

> 
> - 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
-- 
| Felix Kühling <fxkuehl at gmx.de>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |