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
libGLX_${vendor}.so libraries it finds, and call into each to
find which vendor (and possibly which GPU) matches the specified
string. Once a vendor is selected, the vendor library could optionally
tell the X server which GLX vendor to use server-side for this
client connection.
I'm not a huge fan of the "dlopen everything" approach, if it can be
avoided.
Yes, I agree.
I'm pretty sure libglvnd could avoid unnecessarily loading vendor
libraries without adding nearly so much complexity.
If libglvnd just has a list of additional vendor library names to try,
then you could just have a flag to tell libglvnd to check some server
string for that name before it loads the vendor. If a client-side vendor
would need a server-side counterpart to work, then libglvnd can check
for that. The server only needs to keep a list of names to send back,
which would be a trivial (and backward-compatible) addition to the
GLXVND interface.
Also, even without that, I don't think the extra dlopen calls would be a
problem in practice. It would only ever happen in applications that are
configured for offloading, which are (more-or-less by definition)
heavy-weight programs, so an extra millisecond or so of startup time is
probably fine.
I think I'd rather have a new enum for GLXQueryServerString
that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
with the returned string a space-delimited list of :.
libGL could accept either a profile or a vendor name in the environment
variable, and the profile can be either semantic like
performance/battery, or a hardware selector, or whatever else.
This would probably be a layered extension, call it GLX_EXT_libglvnd2,
which you'd check for in the (already per-screen) server extension
string before trying to actually use.
That all sounds reasonable to me.
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 (I think? Are y'all doing that from your libglx instead?), and
when that initializes it already knows which device it's driving.
Right. It will be easy enough for the NVIDIA X driver + NVIDIA server-side GLX.
Kyle and I were chatting about this, and we weren't sure whether people
would object to doing that for the Xorg GLX provider: to create the
hardware names, Xorg's GLX would need to enumerate all the DRM devices
and list them all as possible : pairs for the Xorg
GLX-driven screens. But, now that I look at it more closely, it looks
like drmGetDevices2() would work well for that.
So, if you're not concerned with that burden, I'm not. I'll try coding
up the Xorg GLX part of things and see how it falls into place.
That actually is one of my big concerns: I'd like to come up with
something that can give something equivalent to Mesa's existing
DRI_PRIME setting, and requiring that logic to be in the server seems
like a very poor match. You'd need to take all of the device selection
and enumeration stuff from Mesa and transplant it into the Xorg GLX
module, and then you'd need to define some sort of protocol to get that
data back into Mesa where you actually need it. Or else you need to
duplicate it between the client and server, which seems like the worst
of both worlds.
By comparison, if libglvnd just hands the problem off to the vendor
libraries, then you could do either. A vendor library could do its
device enumeration in the client like Mesa does, or it could send a
request to query something from the server, using whatever protocol you
want -- whatever makes the most sense for that particular driver.
More generally, I worry that defining a (vendor+device+descriptor) list
as an interface between libglvnd and the server means baking in a lot of
unnecessary assumptions and requirements for drivers that we could
otherwise avoid without losing any functionality.
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.
Two follow-up questions:
(1) Even when direct-rendering, NVIDIA's OpenGL/GLX implementation sends
GLX protocol (MakeCurrent, etc). So, we'd like something client-side
to be able to request that server-side GLXVND route GLX protocol for the
calling client connection
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
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
> > libGLX_${vendor}.so libraries it finds, and call into each to
> > find which vendor (and possibly which GPU) matches the specified
> > string. Once a vendor is selected, the vendor library could optionally
> > tell the X server which GLX vendor to use server-side for this
> > client connection.
>
> I'm not a huge fan of the "dlopen everything" approach, if it can be
> avoided.
Yes, I agree.
> I think I'd rather have a new enum for GLXQueryServerString
> that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
> with the returned string a space-delimited list of :.
> libGL could accept either a profile or a vendor name in the environment
> variable, and the profile can be either semantic like
> performance/battery, or a hardware selector, or whatever else.
>
> This would probably be a layered extension, call it GLX_EXT_libglvnd2,
> which you'd check for in the (already per-screen) server extension
> string before trying to actually use.
That all sounds reasonable to me.
> > 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 (I think? Are y'all doing that from your libglx instead?), and
> when that initializes it already knows which device it's driving.
Right. It will be easy enough for the NVIDIA X driver + NVIDIA server-side GLX.
Kyle and I were chatting about this, and we weren't sure whether people
would object to doing that for the Xorg GLX provider: to create the
hardware names, Xorg's GLX would need to enumerate all the DRM devices
and list them all as possible : pairs for the Xorg
GLX-driven screens. But, now that I look at it more closely, it looks
like drmGetDevices2() would work well for that.
So, if you're not concerned with that burden, I'm not. I'll try coding
up the Xorg GLX part of things and see how it falls into place.
Two follow-up questions:
(1) Even when direct-rendering, NVIDIA's OpenGL/GLX implementation sends
GLX protocol (MakeCurrent, etc). So, we'd like something client-side
to be able to request that server-side GLXVND route GLX protocol for the
calling client connection to a specific vendor (on a per-screen basis).
Do you think it would be reasonable for GLX_EXT_libglvnd2 to define a
new protocol request, that client-side libglvnd uses, and sends either
the profile or vendor name from the selected ':'?
(2) Who should decide which vendor/gpu gets the semantic name
"performance" or "battery"? They are relative, so I don't know that
vendors can decide for themselves in isolation. It kind of feels
like it should be GLXVND's job, but I don't know that it has enough
context to infer. I'm curious if anyone else has ideas.
Thanks,
- Andy
> - 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: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
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
> libGLX_${vendor}.so libraries it finds, and call into each to
> find which vendor (and possibly which GPU) matches the specified
> string. Once a vendor is selected, the vendor library could optionally
> tell the X server which GLX vendor to use server-side for this
> client connection.
I'm not a huge fan of the "dlopen everything" approach, if it can be
avoided. I think I'd rather have a new enum for GLXQueryServerString
that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
with the returned string a space-delimited list of :.
libGL could accept either a profile or a vendor name in the environment
variable, and the profile can be either semantic like
performance/battery, or a hardware selector, or whatever else.
This would probably be a layered extension, call it GLX_EXT_libglvnd2,
which you'd check for in the (already per-screen) server extension
string before trying to actually use.
> 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 (I think? Are y'all doing that from your libglx instead?), and
when that initializes it already knows which device it's driving.
- 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
RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
(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 loaded into the X server register themselves
on a per-screen basis, GLXVND in the server dispatches GLX requests to
the registered vendor per screen, and libglvnd determines the client-side
vendor library to use by querying the per-screen GLX_VENDOR_NAMES_EXT
string from the X server (e.g., "mesa" or "nvidia").
The GLX_VENDOR_NAMES_EXT string can be overridden within libglvnd
through the __GLX_VENDOR_LIBRARY_NAME environment variable, though I
don't believe that is used much currently.
To enable GLX to be used in a multi-vendor PRIME GPU offload environment,
it seems there are several desirable user-visible behaviors:
* By default, users should get the same behavior we have today (i.e.,
the GLX implementation used within the client and the server, for an X
screen, is dictated by the X driver of the X screen).
* The user should be able to request a different GLX vendor for use on a
per-process basis through either an environment variable (potentially
reusing __GLX_VENDOR_LIBRARY_NAME) or possibly a future application
profile mechanism in libglvnd.
* To make configuration optionally more "portable", the selection override
mechanism should be able to refer to more generic names like
"performance" or "battery", and those generic names should be mapped
to specific GPUs/vendors on a per-system basis.
* To make configuration optionally more explicit, the selection override
mechanism should be able to distinguish between individual GPUs by
using hardware specific identifiers such as PCI BusID-based names like
what DRI_PRIME currently honors (e.g., "pci-_03_00_0").
Do those behaviors seem reasonable?
If so, it seems like there are two general directions we could take to
implement that infrastructure in client-side libglvnd and GLXVND within
the X server, if the user or application profile requests a particular
vendor, either by vendor name (e.g., "mesa"/"nvidia"), functional
name (e.g., "battery"/"performance"), or hardware-based name (e.g.,
"pci-_03_00_0"/pci-_01_00_0"):
(1) If configured for PRIME GPU offloading (environment variable or
application profile), client-side libglvnd could load the possible
libGLX_${vendor}.so libraries it finds, and call into each to
find which vendor (and possibly which GPU) matches the specified
string. Once a vendor is selected, the vendor library could optionally
tell the X server which GLX vendor to use server-side for this
client connection.
(2) The GLX implementations within the X server could, when registering
with GLXVND, tell GLXVND which screens they can support for PRIME
GPU offloading. That list could be queried by client-side libglvnd,
and then used to interpret __GLX_VENDOR_LIBRARY_NAME and pick the
corresponding vendor library to load. Client-side would tell the X
server which GLX vendor to use server-side for this client connection.
In either direction, if the user-requested string is a hardware-based
name ("pci-_03_00_0"), the GLX vendor library presumably needs to be
told that GPU, so that the vendor implementation can use the right GPU
(in the case that the vendor supports multiple GPUs in the system).
But, both (1) and (2) are really just points on a continuum. I suppose
the more general question is: how much of the implementation should go
in the server and how much should go in the client?
At one extreme, the client could do nearly all the work (with the
practical downside of potentially loading multiple vendor libraries in
order to interpret __GLX_VENDOR_LIBRARY_NAME).
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'm not sure where on that spectrum it makes the most sense to land,
and I'm curious what others think.
Thanks,
- Andy
___
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: [PATCH app/xinit] Buffer overflow with many arguments.
> Tobias Stoeckmann hat am 7. Februar 2019 um 20:54
> geschrieben:
>
>
> Command line arguments are copied into clientargv and serverargv without
> verifying that enough space is available. A high amount of arguments can
> therefore trigger a buffer overflow like this:
>
> $ xinit $(seq 1 500)
>
> Signed-off-by: Tobias Stoeckmann
works for me
Reviewed-by: Walter Harms wharms@bfs,de
> ---
> Integrated calculation as suggested by Walter with style according to
> rest of the code.
> ---
> xinit.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/xinit.c b/xinit.c
> index f826b7a..06c92b2 100644
> --- a/xinit.c
> +++ b/xinit.c
> @@ -151,7 +151,6 @@ main(int argc, char *argv[])
> register char **ptr;
> pid_t pid;
> int client_given = 0, server_given = 0;
> -int client_args_given = 0, server_args_given = 0;
> int start_of_client_args, start_of_server_args;
> struct sigaction sa, si;
> #ifdef __APPLE__
> @@ -174,7 +173,8 @@ main(int argc, char *argv[])
> }
> start_of_client_args = (cptr - client);
> while (argc && strcmp(*argv, "--")) {
> -client_args_given++;
> +if (cptr > clientargv + sizeof(clientargv) / sizeof(*clientargv) - 2)
> +Fatalx("too many client arguments");
> *cptr++ = *argv++;
> argc--;
> }
> @@ -202,7 +202,8 @@ main(int argc, char *argv[])
>
> start_of_server_args = (sptr - server);
> while (--argc >= 0) {
> -server_args_given++;
> +if (sptr > serverargv + sizeof(serverargv) / sizeof(*serverargv) - 2)
> +Fatalx("too many server arguments");
> *sptr++ = *argv++;
> }
> *sptr = NULL;
> --
> 2.20.1
>
> ___
> 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
___
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
