On 10/08/2015 08:44 PM, Michel Dänzer wrote:
On 07.10.2015 04:58, Kyle Brenneman wrote:
On 10/06/2015 12:43 PM, Emil Velikov wrote:
On 6 October 2015 at 16:39, Kyle Brenneman <kbrenne...@nvidia.com> wrote:
On 10/06/2015 07:34 AM, Emil Velikov wrote:
* The existing x11glvnd extension seems to be a "xserver only" approach.
Iirc at XDC last year, people were leaning towards using an FD to
obtain all the information needed. Currently mesa/xserver uses that to
detect if we should load i915, i965, r300, r600... driver. What's your
take on this ?
I'm open to alternatives, but I'm not familiar with the FD approach you're
describing. Can you give me more details about it, or point me at where in
the Mesa code it is?
The idea is that you can get the device(node) fd from the server
(x,weston,foo) and use that to communicate with the module and/apply
any form of heuristics. Currently mesa has a few:
- get the kernel module name (via ioctls or sysfs) and map it to the
userspace driver.
- get the vendor/device pciid (via libudev or sysfs), and map it to
the userspace driver.
The code is in src/loader, it's a bit hard to look at, so be warned.
I've been planning to nuke the ioctl vs sysfs vs libudev, by pushing
the chaos to libdrm. So that others can reuse it when needed. yet it's
not the most interesting thing to do bth.
The only thing that libGLX can assume is that each X screen corresponds
to at most one vendor library.
Actually, it can't: the amdgpu kernel driver is not only supported by
the Mesa radeonsi driver but will also be supported by future versions
of the Catalyst OpenGL driver. Either OpenGL driver will work with both
the xf86-video-amdgpu driver and the generic modesetting Xorg driver.
The x11glvnd extension will (by default) hand back the name of whatever
video driver is driving a screen. For cases where multiple vendor names
should all use the same vendor library, all the different names would
just be symlinks to the same library. So for example, you might have
have libGLX_mesa.so as the library, and then you'd have symlinks to it
named libGLX_intel.so, libGLX_vesa.so, and so on.
I hope we can handle the above scenario as well, allowing to select one
of the supported OpenGL drivers for each application without having to
resort to manipulating symlinks, e.g. via configuration files and/or
environment variables. I think something like Mesa's driconf
infrastructure would be nice for this from a user perspective, it allows
making persistent per-application configuration.
The symlinks idea is more for the reverse of that scenario. When you've
got multiple server-side display drivers that all call for the same
client-side vendor library, then you can add symlinks so that each name
gets you the same library. There's no variation on configuration in that
case, so the installer or package manager would just create the symlinks
and leave it at that.
If there are multiple possible vendor libraries for a single display
driver, then it would need some way to select one. On the server side,
you can set an X config option to override the vendor name that the
x11glvnd extension sends back, and on the client side you can set an
environment variable that would override the vendor library selection in
libGLX. Both of those require manual configuration, though.
For simple cases where two vendor libraries might be available, but
you'd always want to pick one over the other, it might be possible for
the x11glvnd extension to send back multiple names, assuming there was
some way to figure out what those names should be.
But, I think a config file of some sort would be a better overall
solution. It would be more flexible, and would lend itself better to
per-application configuration.
Also note that the vendor library selection logic is internal to libGLX,
so we can still hammer out the rest of the interface in the meantime.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
