Re: RFC - GLX Extension to control GLXVND dispatching for PRIME GPU offloading

On 4/23/19 4:28 PM, Aaron Plattner wrote: On 4/17/19 8:51 AM, Kyle Brenneman wrote: For GPU offloading in libglvnd, where individual clients can run with an alternate GPU and client-side vendor library, we'd need some way for that alternate vendor library to communicate with its server-side

RFC - GLX Extension to control GLXVND dispatching for PRIME GPU offloading

nts and questions welcome. -Kyle Brenneman Name EXT_server_vendor_select Name Strings GLX_EXT_server_vendor_select Contact Kyle Brenneman, NVIDIA, kbrenneman at nvidia.com Contributors Kyle Brenneman Status XXX - Not complete yet!!! Version Last Modified Date: April 11, 2

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

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

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

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

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

On 02/11/2019 02:51 PM, Andy Ritger wrote: On Fri, Feb 08, 2019 at 03:43:25PM -0700, Kyle Brenneman wrote: On 2/8/19 2:33 PM, Andy Ritger wrote: On Fri, Feb 08, 2019 at 03:01:33PM -0500, Adam Jackson wrote: On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote: (1) If configured for PRIME

Re: RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload

On 02/08/2019 11:19 AM, Andy Ritger wrote: (I'll omit EGL and Vulkan for the moment, for the sake of focus, and those APIs have programmatic ways to enumerate and select GPUs. Though, some of what we decide here for GLX we may want to leverage for other APIs.) Today, GLX implementations

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

On 2/8/19 2:33 PM, Andy Ritger wrote: On Fri, Feb 08, 2019 at 03:01:33PM -0500, Adam Jackson wrote: On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote: (1) If configured for PRIME GPU offloading (environment variable or application profile), client-side libglvnd could load the possible

[PATCH xserver] GLX: Fix a use after free error with the GLVND vendor handle.

The GLVND layer will destroy all of the vendor handles at the end of each server generation, but the GLX module then tries to re-use the same (now-freed) handle in xorgGlxServerInit at the start of the next generation. In xorgGlxCloseExtension, explicitly destroy the vendor handle and set it to

[PATCH RFC xserver] Don't delete GLX's extensionInitCallback list during a reset

Using a CallbackListPtr to handle InitExtensions for GLX vendor libraries works on the first server generation, but at the end of the generation, the server will clear the callback list. On the second generation and beyond, every screen ends up with NULL for the vendor handle assigned to it. This

[PATCH xserver] Don't delete GLX's extensionInitCallback list during a reset.

When a callback list is initialized using CreateCallbackList via AddCallback, the list gets added to the listsToCleanup array, and as a result the list gets deleted at the end of the server generation. But, vendor libraries add themselves to that callback list only once, not once per generation,

Re: [PATCH xserver 2/4] glx: Use vnd layer for dispatch (v3)

: Add/remove the XID map from the vendor private thunk, not the backend. (Kyle Brenneman) Signed-off-by: Adam Jackson <a...@redhat.com> --- configure.ac | 2 +- glx/createcontext.c| 2 - glx/glxcmds.c | 212 +

Re: [PATCH xserver 4/7] glx: Use vnd layer for dispatch (v2)

On 02/01/2018 02:31 PM, Adam Jackson wrote: On Wed, 2018-01-10 at 13:57 -0700, Kyle Brenneman wrote: xorgGlxThunkRequest should be calling addXIDMap and removeXIDMap, not the internal handlers. I'm not sure that can be right. If it did, and adding the map failed, there's no way to get

Re: [PATCH xserver 4/7] glx: Use vnd layer for dispatch (v2)

On 01/10/2018 01:57 PM, Kyle Brenneman wrote: On 01/10/2018 11:05 AM, Adam Jackson wrote: The big change here is MakeCurrent and context tag tracking. We now delegate context tags entirely to the vnd layer, and simply store a pointer to the context state as the tag data. If a context

Re: [PATCH xserver 4/7] glx: Use vnd layer for dispatch (v2)

On 01/10/2018 11:05 AM, Adam Jackson wrote: The big change here is MakeCurrent and context tag tracking. We now delegate context tags entirely to the vnd layer, and simply store a pointer to the context state as the tag data. If a context is deleted while it's current, we allocate a fake ID for

[RFC PATCH] glxvnd: Various fixes

This is a follow-on to the GLXVND patches by Adam Jackson, sent out on 8/30/2017. This still mostly proof-of-concept, but it's enough to at least build and run. Fix various compiler warnings. Fix GlxGetXIDMap so that it calls dixLookupResourceByClass instead of dixLookupResourceByType. Update

Re: [RFC PATCH xserver 0/5] Server-side vendor neutral dispatch for GLX

On 08/30/2017 12:58 PM, Adam Jackson wrote: The idea here is that the DDX creates a GLX provider during AddScreen, and then GlxExtensionInit walks the list of created providers and calls their setup functions to initialize GLX for a screen. If you have heterogeneous GPUs in a Zaphod setup this

Re: [PATCH xserver 3/5] glx: Import glxvnd server module

On 08/30/2017 12:58 PM, Adam Jackson wrote: From: Kyle Brenneman <kbrenne...@nvidia.com> This is based on an out-of-tree module written by Kyle: https://github.com/kbrenneman/libglvnd/tree/server-libglx I (ajax) did a bunch of cosmetic fixes, ported it off xfree86 API, added request

Re: [RFC] Server side glvnd

I was actually just getting ready to send this out. This is what I've come up with for a server-side GLVND-like interface: https://github.com/kbrenneman/libglvnd/tree/server-libglx What I've got there is a proof-of-concept GLX server module that can dispatch to multiple vendor libraries based

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

EGL_PLATFORM=amdgpu-pro when init, unset when init is done. Regards, Qiang From: Kyle Brenneman <kbrenne...@nvidia.com> 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

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

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 <kbre

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

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 <kbrenne...@nvidia.com> Sent: Wednesday, December 28, 2016 1:05:50 AM To: Yu,

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

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 (iir

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

On 12/15/2016 10:53 AM, Hans de Goede wrote: Hi, On 15-12-16 17:08, Emil Velikov wrote: On 15 December 2016 at 08:15, Michel Dänzer wrote: Hi Adam, Andy, Kyle, even with GLVND in place and used by Mesa and other GL implementations, one remaining issue preventing