[Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL
Michel Dänzer
michel at daenzer.net
Thu Oct 8 19:44:07 PDT 2015
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.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list