date:20161227

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

2016-12-27 Thread Yu, Qiang


Thanks Kyle, that's wonderful!

Regards,
Qiang

From: Kyle Brenneman 
Sent: Wednesday, December 28, 2016 3:23:04 PM
To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

The driver order is configurable, and typically set when the drivers are
installed.

Each driver adds a JSON file to a directory to specify the name of the
library, similar to the way the Vulkan loader finds ICD's. libEGL sorts
those by filename, which defines the order that it'll try each driver.
Then, when the app calls eglGetPlatformDisplay, it uses whatever driver
succeeds first.

You can override that order by setting the environment variable
__EGL_VENDOR_LIBRARY_FILENAMES to a colon-separated list of JSON files.
Note that libEGL only reads those files once, though, when it first
loads the vendor libraries. Setting the environment variable right
before calling eglGetPlatformDisplay may not work if you've called any
other EGL functions beforehand.

-Kyle

On 12/27/2016 11:43 PM, Yu, Qiang wrote:
> For EGL, when the app calls eglGetPlatformDisplay or
> eglGetDisplay(EGL_DEFAULT_DISPLAY), then libglvnd will just try each
> driver in the order they're listed until it finds one that works. You
> could select between two drivers based on an environment variable like
> DRI_PRIME just by having one driver or the other succeed.
>
> [yuq] You mean if both vendor driver work for a call, the first success one 
> will
> be chosen, and an environment variable in first vendor driver can be used to
> choose return fail if it is not what we want? If work like this, can we
> specify the driver list order? Because vendor can only change its own driver
> to add this environment variable. Otherwise we need to add this env to mesa.
>
> Regards,
> Qiang
>
> On 12/27/2016 08:26 PM, Yu, Qiang wrote:
>> So use like this per application?
>> DRI_PRIME=1 __GLX_VENDOR_LIBRARY_NAME=xxx glxgears
>> DRI_PRIME=1 EGL_PLATFORM=xxx es2gears
>>
>> Another problem is if two EGL vendor can both be used, how do I
>> select which to use within one application? For example, in xserver,
>> load two DDX for two GPU: modesetting DDX use mesa EGL,
>> amdgpu DDX use amdgpu-pro EGL (it can use mesa too).
>> The interface is the same (both is initialized from gbm fd).
>> Which is the default one?
>>
>> Will this work? In amdgpu DDX code temporarily set EGL_PLATFORM=amdgpu-pro
>> when init, unset when init is done.
>>
>> Regards,
>> Qiang
>> 
>> From: Kyle Brenneman 
>> Sent: Wednesday, December 28, 2016 10:18:13 AM
>> To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
>> Cc: ML xorg-devel
>> Subject: Re: Xorg glx module: GLVND, EGL, or ... ?
>>
>> GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's
>> very driver-specific), but it has an environment variable that you can
>> use to override which vendor library it selects.
>>
>> That's entirely on the client side, so whatever driver to tell it to use
>> still needs to be able to talk to the server.
>>
>> -Kyle
>>
>> On 12/27/2016 07:06 PM, Yu, Qiang wrote:
>>> 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:
>>>  
>>>
>>> What's your opinion?
>>>
>>> Regards,
>>> Qiang
>>> 
>>> From: Kyle Brenneman 
>>> 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 
 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 ... ?

2016-12-27 Thread Kyle Brenneman

The driver order is configurable, and typically set when the drivers are 
installed.


Each driver adds a JSON file to a directory to specify the name of the 
library, similar to the way the Vulkan loader finds ICD's. libEGL sorts 
those by filename, which defines the order that it'll try each driver. 
Then, when the app calls eglGetPlatformDisplay, it uses whatever driver 
succeeds first.


You can override that order by setting the environment variable 
__EGL_VENDOR_LIBRARY_FILENAMES to a colon-separated list of JSON files. 
Note that libEGL only reads those files once, though, when it first 
loads the vendor libraries. Setting the environment variable right 
before calling eglGetPlatformDisplay may not work if you've called any 
other EGL functions beforehand.


-Kyle

On 12/27/2016 11:43 PM, Yu, Qiang wrote:

For EGL, when the app calls eglGetPlatformDisplay or
eglGetDisplay(EGL_DEFAULT_DISPLAY), then libglvnd will just try each
driver in the order they're listed until it finds one that works. You
could select between two drivers based on an environment variable like
DRI_PRIME just by having one driver or the other succeed.

[yuq] You mean if both vendor driver work for a call, the first success one will
be chosen, and an environment variable in first vendor driver can be used to
choose return fail if it is not what we want? If work like this, can we
specify the driver list order? Because vendor can only change its own driver
to add this environment variable. Otherwise we need to add this env to mesa.

Regards,
Qiang

On 12/27/2016 08:26 PM, Yu, Qiang wrote:

So use like this per application?
DRI_PRIME=1 __GLX_VENDOR_LIBRARY_NAME=xxx glxgears
DRI_PRIME=1 EGL_PLATFORM=xxx es2gears

Another problem is if two EGL vendor can both be used, how do I
select which to use within one application? For example, in xserver,
load two DDX for two GPU: modesetting DDX use mesa EGL,
amdgpu DDX use amdgpu-pro EGL (it can use mesa too).
The interface is the same (both is initialized from gbm fd).
Which is the default one?

Will this work? In amdgpu DDX code temporarily set EGL_PLATFORM=amdgpu-pro
when init, unset when init is done.

Regards,
Qiang

From: Kyle Brenneman 
Sent: Wednesday, December 28, 2016 10:18:13 AM
To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's
very driver-specific), but it has an environment variable that you can
use to override which vendor library it selects.

That's entirely on the client side, so whatever driver to tell it to use
still needs to be able to talk to the server.

-Kyle

On 12/27/2016 07:06 PM, Yu, Qiang wrote:

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:
 

What's your opinion?

Regards,
Qiang

From: Kyle Brenneman 
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 
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 +, 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

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

2016-12-27 Thread Yu, Qiang


More clearly I think it will be good to have an environment variable in GLVND
can specify the EGL vendor driver try order like:
GLVND_EGL_VENDOR_ORDER=amdgpu-pro:mesa

So amdgpu-pro vendor driver is tried first and return fail on non-amd GPUs
and no need an environment variable in both mesa and amdgpu-pro.

Regards,
Qiang

From: Yu, Qiang
Sent: Wednesday, December 28, 2016 2:43:38 PM
To: Kyle Brenneman; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

For EGL, when the app calls eglGetPlatformDisplay or
eglGetDisplay(EGL_DEFAULT_DISPLAY), then libglvnd will just try each
driver in the order they're listed until it finds one that works. You
could select between two drivers based on an environment variable like
DRI_PRIME just by having one driver or the other succeed.

[yuq] You mean if both vendor driver work for a call, the first success one will
be chosen, and an environment variable in first vendor driver can be used to
choose return fail if it is not what we want? If work like this, can we
specify the driver list order? Because vendor can only change its own driver
to add this environment variable. Otherwise we need to add this env to mesa.

Regards,
Qiang

On 12/27/2016 08:26 PM, Yu, Qiang wrote:
> So use like this per application?
> DRI_PRIME=1 __GLX_VENDOR_LIBRARY_NAME=xxx glxgears
> DRI_PRIME=1 EGL_PLATFORM=xxx es2gears
>
> Another problem is if two EGL vendor can both be used, how do I
> select which to use within one application? For example, in xserver,
> load two DDX for two GPU: modesetting DDX use mesa EGL,
> amdgpu DDX use amdgpu-pro EGL (it can use mesa too).
> The interface is the same (both is initialized from gbm fd).
> Which is the default one?
>
> Will this work? In amdgpu DDX code temporarily set EGL_PLATFORM=amdgpu-pro
> when init, unset when init is done.
>
> Regards,
> Qiang
> 
> From: Kyle Brenneman 
> Sent: Wednesday, December 28, 2016 10:18:13 AM
> To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
> Cc: ML xorg-devel
> Subject: Re: Xorg glx module: GLVND, EGL, or ... ?
>
> GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's
> very driver-specific), but it has an environment variable that you can
> use to override which vendor library it selects.
>
> That's entirely on the client side, so whatever driver to tell it to use
> still needs to be able to talk to the server.
>
> -Kyle
>
> On 12/27/2016 07:06 PM, Yu, Qiang wrote:
>> 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:
>>  
>>
>> What's your opinion?
>>
>> Regards,
>> Qiang
>> 
>> From: Kyle Brenneman 
>> 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 
>>> 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 +, 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

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

2016-12-27 Thread Kyle Brenneman

The __GLX_VENDOR_LIBRARY_NAME variable is enough to force libGLX.so to 
use a specific driver instead of whatever name the X server sends back. 
Whether the DRI_PRIME variable would be needed depends on the driver 
that you give it.


For EGL, when the app calls eglGetPlatformDisplay or 
eglGetDisplay(EGL_DEFAULT_DISPLAY), then libglvnd will just try each 
driver in the order they're listed until it finds one that works. You 
could select between two drivers based on an environment variable like 
DRI_PRIME just by having one driver or the other succeed.


Setting EGL_PLATFORM only affects a call to eglGetDisplay with a 
non-NULL native display, where it has to guess which platform to use. In 
a case where you know you're using GBM, it's better to just use 
eglGetPlatformDisplay.


-Kyle

On 12/27/2016 08:26 PM, Yu, Qiang wrote:

So use like this per application?
DRI_PRIME=1 __GLX_VENDOR_LIBRARY_NAME=xxx glxgears
DRI_PRIME=1 EGL_PLATFORM=xxx es2gears

Another problem is if two EGL vendor can both be used, how do I
select which to use within one application? For example, in xserver,
load two DDX for two GPU: modesetting DDX use mesa EGL,
amdgpu DDX use amdgpu-pro EGL (it can use mesa too).
The interface is the same (both is initialized from gbm fd).
Which is the default one?

Will this work? In amdgpu DDX code temporarily set EGL_PLATFORM=amdgpu-pro
when init, unset when init is done.

Regards,
Qiang

From: Kyle Brenneman 
Sent: Wednesday, December 28, 2016 10:18:13 AM
To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's
very driver-specific), but it has an environment variable that you can
use to override which vendor library it selects.

That's entirely on the client side, so whatever driver to tell it to use
still needs to be able to talk to the server.

-Kyle

On 12/27/2016 07:06 PM, Yu, Qiang wrote:

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:
 

What's your opinion?

Regards,
Qiang

From: Kyle Brenneman 
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 
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 +, 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


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2016-12-27 Thread Yu, Qiang


So use like this per application?
DRI_PRIME=1 __GLX_VENDOR_LIBRARY_NAME=xxx glxgears
DRI_PRIME=1 EGL_PLATFORM=xxx es2gears

Another problem is if two EGL vendor can both be used, how do I
select which to use within one application? For example, in xserver,
load two DDX for two GPU: modesetting DDX use mesa EGL,
amdgpu DDX use amdgpu-pro EGL (it can use mesa too).
The interface is the same (both is initialized from gbm fd).
Which is the default one?

Will this work? In amdgpu DDX code temporarily set EGL_PLATFORM=amdgpu-pro
when init, unset when init is done.

Regards,
Qiang

From: Kyle Brenneman 
Sent: Wednesday, December 28, 2016 10:18:13 AM
To: Yu, Qiang; Adam Jackson; Emil Velikov; Michel Dänzer
Cc: ML xorg-devel
Subject: Re: Xorg glx module: GLVND, EGL, or ... ?

GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's
very driver-specific), but it has an environment variable that you can
use to override which vendor library it selects.

That's entirely on the client side, so whatever driver to tell it to use
still needs to be able to talk to the server.

-Kyle

On 12/27/2016 07:06 PM, Yu, Qiang wrote:
> 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:
>  
>
> What's your opinion?
>
> Regards,
> Qiang
> 
> From: Kyle Brenneman 
> 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 
>> 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 +, 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

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2016-12-27 Thread 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:

What's your opinion?

Regards,
Qiang

From: Kyle Brenneman 
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 
> 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 +, 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

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2016-12-27 Thread Kyle Brenneman

GLVND doesn't respond to DRI_PRIME (and probably shouldn't, since that's 
very driver-specific), but it has an environment variable that you can 
use to override which vendor library it selects.


That's entirely on the client side, so whatever driver to tell it to use 
still needs to be able to talk to the server.


-Kyle

On 12/27/2016 07:06 PM, Yu, Qiang wrote:

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:
 

What's your opinion?

Regards,
Qiang

From: Kyle Brenneman 
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 
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 +, 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


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xts] xts5: Fix clang error - non-void function 'tet_main' should return a value

2016-12-27 Thread Rhys Kidd

Amongst examples:

XDisplayString/Test1.c:151:3: error: non-void function 'tet_main' should return
  a value [-Wreturn-type]
return;
^

Signed-off-by: Rhys Kidd 
---
 xts5/Xlib12/XDisplayName/Test1.c | 3 ++-
 xts5/Xlib15/XSetWMProperties/Test1.c | 6 --
 xts5/Xlib15/XSetWMProperties/Test2.c | 6 --
 xts5/Xlib17/XGetDefault/Test3.c  | 3 ++-
 xts5/Xlib17/XGetDefault/Test4.c  | 3 ++-
 xts5/Xlib17/XGetDefault/Test5.c  | 6 --
 xts5/Xlib3/XDisplayString/Test1.c| 8 +---
 xts5/Xlib3/XOpenDisplay/Test1.c  | 6 --
 8 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/xts5/Xlib12/XDisplayName/Test1.c b/xts5/Xlib12/XDisplayName/Test1.c
index a1bb851..e54d926 100644
--- a/xts5/Xlib12/XDisplayName/Test1.c
+++ b/xts5/Xlib12/XDisplayName/Test1.c
@@ -156,7 +156,8 @@ char*str;
 
if((dispstr = getenv("DISPLAY")) == NULL) {
delete("Environment variable DISPLAY is not set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib15/XSetWMProperties/Test1.c 
b/xts5/Xlib15/XSetWMProperties/Test1.c
index 7c2cf28..6825f2c 100644
--- a/xts5/Xlib15/XSetWMProperties/Test1.c
+++ b/xts5/Xlib15/XSetWMProperties/Test1.c
@@ -156,7 +156,8 @@ XClassHint  rclass_hints;
 
if( (res_name = getenv("RESOURCE_NAME")) == NULL) {
delete("RESOURCE_NAME environment variable is not set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
@@ -172,7 +173,8 @@ XClassHint  rclass_hints;
 
if( XGetClassHint(Dsp, win, _hints) == 0 ) {
delete("XGetClassHints returned zero.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib15/XSetWMProperties/Test2.c 
b/xts5/Xlib15/XSetWMProperties/Test2.c
index d52cef3..f94f239 100644
--- a/xts5/Xlib15/XSetWMProperties/Test2.c
+++ b/xts5/Xlib15/XSetWMProperties/Test2.c
@@ -156,7 +156,8 @@ XClassHint  rclass_hints;
 
if( getenv("RESOURCE_NAME") != (char *)NULL) {
delete("RESOURCE_NAME environment variable was set to \"%s\" 
instead of being undefined.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
@@ -172,7 +173,8 @@ XClassHint  rclass_hints;
 
if( XGetClassHint(Dsp, win, _hints) == 0 ) {
delete("XGetClassHints returned zero.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib17/XGetDefault/Test3.c b/xts5/Xlib17/XGetDefault/Test3.c
index 05ba128..14542b6 100644
--- a/xts5/Xlib17/XGetDefault/Test3.c
+++ b/xts5/Xlib17/XGetDefault/Test3.c
@@ -151,7 +151,8 @@ char
*pval="XTest.testval31:pval_a\nXTest.testval32:pval_b\nXTest.testval33:pva
 
if(getenv("HOME") == NULL) {
delete("Environment variable \"HOME\" is not set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib17/XGetDefault/Test4.c b/xts5/Xlib17/XGetDefault/Test4.c
index 958fa91..5c53dd7 100644
--- a/xts5/Xlib17/XGetDefault/Test4.c
+++ b/xts5/Xlib17/XGetDefault/Test4.c
@@ -154,7 +154,8 @@ static  char*result[]  = { "pVAL_1","eVAL_5",   
 "eVAL_6" };
 
if(getenv("XENVIRONMENT") == NULL) {
delete("XENVIRONMENT environment variable not set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib17/XGetDefault/Test5.c b/xts5/Xlib17/XGetDefault/Test5.c
index 628ba7d..5e506ae 100644
--- a/xts5/Xlib17/XGetDefault/Test5.c
+++ b/xts5/Xlib17/XGetDefault/Test5.c
@@ -157,13 +157,15 @@ staticchar*result[]  = { "pVAL_1","hVAL_5",   
 "hVAL_6" , "hVAL_7"};
 
if(getenv("XENVIRONMENT") != NULL) {
delete("XENVIRONMENT environment variable was set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
if(getenv("HOME") == NULL) {
delete("HOME environment variable was not set.");
-   return;
+   UNRESOLVED;
+   return(False);
} else
CHECK;
 
diff --git a/xts5/Xlib3/XDisplayString/Test1.c 
b/xts5/Xlib3/XDisplayString/Test1.c
index 119d790..d6bce99 100644
--- a/xts5/Xlib3/XDisplayString/Test1.c
+++ b/xts5/Xlib3/XDisplayString/Test1.c
@@ -148,13 +148,15 @@ Display   *display;
 
if((dispstr = getenv("DISPLAY")) == NULL) {
delete("Environment variable DISPLAY is not set.");
-   return;
+   UNRESOLVED;
+

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

2016-12-27 Thread Kyle Brenneman


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 
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 +, 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


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libxi] Fix possible free of uninitialized pointer

2016-12-27 Thread Emilio Pozuelo Monfort

If the _XReply() call fails, we'll try to free an uninitialized
pointer.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849026

Reported-by: Thomas Walker 
Signed-off-by: Emilio Pozuelo Monfort 
Reviewed-by: Julien Cristau 
Tested-by: Thomas Walker 
---
 src/XIQueryDevice.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
index a877d78..51e2d0d 100644
--- a/src/XIQueryDevice.c
+++ b/src/XIQueryDevice.c
@@ -46,7 +46,7 @@ XIQueryDevice(Display *dpy, int deviceid, int 
*ndevices_return)
 char*ptr;
 char*end;
 int i;
-char*buf;
+char*buf = NULL;
 
 XExtDisplayInfo *extinfo = XInput_find_display(dpy);
 
-- 
2.11.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

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

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

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

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

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

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

[PATCH xts] xts5: Fix clang error - non-void function 'tet_main' should return a value

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

[PATCH libxi] Fix possible free of uninitialized pointer

10 matches

Site Navigation

Mail list logo

Footer information