[Mesa-dev] [RFC] GBM Alternate Backend Discovery & Loading

James Jones jajones at nvidia.com
Mon Mar 29 17:47:51 UTC 2021

I've brought this up in the past, but I have some patches implementing 
it now, so I was hoping to get some further feedback on the idea of 
supporting GBM backends external to Mesa.


 From my reading, the GBM core code was intended to support, or perhaps 
at some point in the past did support loading backends other than the 
built-in DRI one. This series extends the current code to enable loading 
of alternate backends in general, and as a straw-man proposal, 
specifically uses the DRM driver name of the FD passed to 
gbm_create_device() to construct a library name of a potential alternate 
backend. Other schemes could be implemented on top of the basic 
functionality added here, but this simple one seemed sufficient.

Issues addressed in the series:

-The ability to dynamically load backends from DSOs.

-Thread-safe tracking and refcounting of dynamically-loaded backends.

-Versioning of the GBM driver ABI to enable backwards and forwards 
binary compatibility between the GBM loader and backends.

-Discovery of alternate/external backend DSOs.

Here's a rundown of the backend discovery logic implemented in the series:

-If the GBM_BACKEND env var is set, attempt to load the backend library 
it names and create a device from it if found.

-If that fails or the env var is not set, call drmGetVersion() on the 
fd, and if that succeeds, attempt to load libgbm_<DRM driver name>.so.0 
and create a device from it if found.

-If that fails, try the built-in DRI backend.


More information about the mesa-dev mailing list