<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 10/08/2015 08:44 PM, Michel Dänzer wrote: <blockquote cite="mid:561729F7.1000800@daenzer.net" type="cite"> <pre wrap="">On 07.10.2015 04:58, Kyle Brenneman wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/06/2015 12:43 PM, Emil Velikov wrote: </pre> <blockquote type="cite"> <pre wrap="">On 6 October 2015 at 16:39, Kyle Brenneman <a class="moz-txt-link-rfc2396E" href="mailto:kbrenneman@nvidia.com"><kbrenneman@nvidia.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/06/2015 07:34 AM, Emil Velikov wrote: </pre> <blockquote type="cite"> <pre wrap=""> * 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 ? </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">The only thing that libGLX can assume is that each X screen corresponds to at most one vendor library. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> 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. </body> </html>