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:
>>> 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
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
