Xorg glx module: GLVND, EGL, or ... ?

[Yu, Qiang]

Yes, mesa can handle DRI_PRIME alone. But my use case is:
1. PRIME GPU (iGPU) use mesa libGL
2. Secondary GPU (dGPU) use close source libGL

If this can be done, we can use dynamic GPU offload in hybrid GPU platforms,
currently we have to switch between GPUs statically (change xorg.conf).

When DRI2, secondary GPU has a GPUScreen on the xserver side which can
be used to obtain vendor info (although not implemented). But DRI3, client
just do offload when DRI_PRIME=1 is set without inform xserver.

The only method I can think of is using a config file for GLVND which records the
secondary GPU's vendor to use when DRI_PRIME is set like:
<pci id> <vendor>

What's your opinion?

Regards,
Qiang
________________________________________
From: Kyle Brenneman <kbrenneman at nvidia.com>
Sent: Wednesday, December 28, 2016 1:05:50 AM
To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

Is DRI_PRIME handled within the Mesa?

If so, then no support from GLVND is needed. The GLVND libraries would
simply dispatch any function calls to Mesa, which in turn would handle
those calls the same way it would in a non-GLVND system.

-Kyle

On 12/23/2016 07:31 PM, Yu, Qiang wrote:
> Hi guys,
>
> Does GLVND support DRI_PRIME=1? If the secondary GPU uses different
> libGL than primary GPU, how GLVND get the vendor to use?
>
> Regards,
> Qiang
> ________________________________________
> From: Adam Jackson <ajax at redhat.com>
> Sent: Saturday, December 17, 2016 6:02:18 AM
> To: Emil Velikov; Michel Dänzer
> Cc: Kyle Brenneman; Yu, Qiang; ML xorg-devel
> Subject: Re: Xorg glx module: GLVND, EGL, or ... ?
>
> On Thu, 2016-12-15 at 16:08 +0000, Emil Velikov wrote:
>
>> Example:
>> Would happen if we one calls glXMakeCurrent which internally goes down
>> to eglMakeCurrent ? Are we going to clash since (iirc) one is not
>> allowed to do both on the same GL ctx ?
> No, for the same reason this already isn't a problem. If you
> glXMakeCurrent an indirect context, the X server does not itself call
> glXMakeCurrent. All it does is record the client's binding. Only when
> we go do to actual indirect rendering (or mutate context state) does
> libglx actually make that context "current". That context is a tuple of
> the protocol state and a DRI driver context; it could just as easily be
> an EGL context instead of DRI.
>
> - ajax