[Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

[Kyle Brenneman]

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 <kbrenneman at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151009/03c1f7df/attachment-0001.html>