[Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload

Kyle Brenneman kbrenneman at nvidia.com
Wed Feb 13 21:40:52 UTC 2019


On 2/13/19 2:32 PM, Andy Ritger wrote:
> On Wed, Feb 13, 2019 at 12:15:02PM -0700, Kyle Brenneman wrote:
>> On 02/12/2019 01:58 AM, Michel Dänzer wrote:
>>> On 2019-02-11 5:18 p.m., Andy Ritger wrote:
>>>> On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
>>>>> On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
>>>>>> Also, is Mesa the only client-side vendor library that works with the
>>>>>> Xorg GLX module? I vaguely remember that there was at least one other
>>>>>> driver that did, but I don't remember the details anymore.
>>>>> AFAIK, the amdgpu-pro OpenGL driver can work with the Xorg GLX module
>>>>> (or its own forked version of it).
>>>> Maybe the amdgpu-pro OpenGL driver uses a fork of the Xorg GLX module
>>>> (or sets the "GlxVendorLibrary" X configuration option?), but it doesn't
>>>> look to me like the in-tree Xorg GLX module could report anything other
>>>> than "mesa" for GLX_VENDOR_NAMES_EXT, without custom user configuration.
>>>>
>>>> GLX_VENDOR_NAMES_EXT, which client-side glvnd uses to pick the
>>>> libGLX_${vendor}.so to load, is implemented in the Xorg GLX module
>>>> with this:
>>>>
>>>>     xserver/glx/glxcmds.c:__glXDisp_QueryServerString():
>>>>
>>>>       case GLX_VENDOR_NAMES_EXT:
>>>>           if (pGlxScreen->glvnd) {
>>>>               ptr = pGlxScreen->glvnd;
>>>>               break;
>>>>           }
>>>>
>>>> pGlxScreen->glvnd appears to be assigned here, defaulting to "mesa",
>>>> though allowing an xorg.conf override via the "GlxVendorLibrary" option:
>>>>
>>>>     xserver/glx/glxdri2.c:__glXDRIscreenProbe():
>>>>
>>>>       xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, options);
>>>>       glvnd = xf86GetOptValString(options, GLXOPT_VENDOR_LIBRARY);
>>>>       if (glvnd)
>>>>           screen->base.glvnd = xnfstrdup(glvnd);
>>>>       free(options);
>>>>
>>>>       if (!screen->base.glvnd)
>>>>           screen->base.glvnd = strdup("mesa");
>>>>
>>>> And swrast unconditionally sets pGlxScreen->glvnd to "mesa":
>>>>
>>>>     xserver/glx/glxdriswrast.c:__glXDRIscreenProbe():
>>>>
>>>>       screen->base.glvnd = strdup("mesa");
>>>>
>>>> Is there more to this that I'm missing?
>>> I don't think so, I suspect we were just assuming slightly different
>>> definitions of "works". :)
>>>
>>>
>> That should get fixed, but since that applies to the libglvnd's normal
>> vendor selection, I'd say it's orthogonal to GPU offloading. Off the top of
>> my head, the "GlxVendorLibrary" option ought to work regardless of which
>> __GLXprovider it finds. I think it would be possible to add a function to
>> let a driver override the GLX_VENDOR_NAMES_EXT string, too.
> I think the point, though, is that thus far, libGLX_mesa.so is the only
> glvnd client-side GLX implementation that will be loaded for use with
> Xorg's GLX.  Thus, it doesn't seem to refute ajax's comment from earlier
> in the thread:
I don't see that those are related. The GLX_VENDOR_NAMES_EXT string 
tells libglvnd which vendor to use by default. GPU offloading, more or 
less by definition, means using something other than the default.

>>>> At the other extreme, the server could do nearly all the work of
>>>> generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
>>>> practical downside of each server-side GLX vendor needing to enumerate
>>>> the GPUs it can drive, in order to generate the hardware-specific
>>>> identifiers).
>>> I don't think this downside is much of a burden? If you're registering
>>> a provider other than Xorg's you're already doing it from the DDX
>>> driver
>
>> -Kyle
>>



More information about the mesa-dev mailing list