Repository navigation
glxgears uses software instead of hardware accellerated rendering #1
Description
Activity
Yes, the driver is part of the runtime, and does not have any virtualbox specific drivers.
However, i've made /usr/lib/GL an extension point in the runtime, due to this part of the metadata:
[Extension org.freedesktop.Platform.GL] directory=lib/GLThis means that if you have a runtime installed called org.freedesktop.Platform.GL it will be mounted over /usr/lib/GL in the app, allowing you to replace libGL.
I've never actually tested this, but this may be a good time to try it.
From @porst17 on June 17, 2015 16:55
You need at least two files in the app: the
libGL.soand the requested DRI driver. Otherwise, direct rendering won't work which usually means that the application falls back to software rendering (and ancient OpenGL 1.4). In the case of VirtualBox, the DRI driver isvboxvideo_dri.so. I don't know if additional files are needed. Since the driver supplies thelibGL.soin Linux, the mechanism for DRI support may be different for different drivers. I am just speculating here. Maybe there is a standard approach for this problem. I also don't know, wherelibGLget's the instructions from to load thevboxvideoDRI driver. X server setting? Graphics driver kernel module?Yeah, GL support is kinda wonky, in that custom drivers basically scribble all over libGL.so.
The way i built the runtime is that all the GL related libraries are in /usr/lib/GL, and /usr/lib/libGL.so is a symlink into that. So, you should be able to replace everything in there with your custom driver in a separate extension runtime (with just the libGL.so and related files)Oh, hardware acceleration already works for the drivers that are in the runtime, it just does not contain the vmware driver.
From @porst17 on June 18, 2015 9:21
... but how do you ensure that the correct version of the driver is contained in the runtime? The graphics driver provides
libGL.soas well as some kernel module + DRI driver and AFAIK all files should originate from the same version of the driver. I can't imagine that the kernel module version X.X.X on the host plays well with libGL.so version Y.Y.Y in the runtime. If this works for you, this sound like good luck to me or not?Using the
org.freedesktop.Platform.GLextension runtime approach would mean to provide a runtime for each specific driver in each available version, doesn't it?Yes, the runtime bundles some version of the mesa dri driver. If you need a different driver, say the nvidia kernel module you need to install that packaged as a org.freedesktop.Platform.GL runtime.
The runtime packages both libGL and dri userspace drivers of compatible versions. And yes, obviously these need a matching kernel driver. However, the dri kernel/userspace API is not identical wrt versions. Generally a dri userspace driver works with older versions of the kernel driver. For instance, you're able to build the latest upstream kernel and run it on your box even if you have the same (older) dri userspace drivers. The same may not be true for other drivers (say nvidia) though.
From @porst17 on June 18, 2015 10:38
Is this process automated somehow? I mean, who is going to package the extension runtimes and are they downloaded and selected automatically to match my system configuration? I mean, not now, but maybe in the future. The same might be needed for other libraries which directly rely on certain hardware features and kernel modules (I am thinking of, maybe, digital audio processing and special input devices like Leap Motion etc.). Overall, after thinking a little bit more about it, the extension runtime idea doesn't sound too bad anymore.
The current system has nothing like that, but overall its pretty low-level. It only has ops to install or update a named runtime/app. I can easily imagine a higher level layer kinda like the yum/rpm or apt/dpkg splits that have more smarts.
From @malex984 on June 18, 2015 12:17
Hi All.
Unfortunately i have very little knowledge about SandboxedApps and Runtimes. My current impression is that you model them after Application and Framework Bundles from OSX ( https://en.wikipedia.org/wiki/Bundle_(OS_X) ).
Moreover i don't know much about Wayland-to-X11 adapters and can only assume that it behaves like X11 server together with all the client bits.Please do correct me if i am wrong about some of the above!
Now to GPU-related drivers. Please let me give a summary of my findings with virtualbox guest additions and nvidia GPU drivers.
It seems that usually at least 3 things are provided:
- Linux kernel modules for pci device: I don't think it is really possible to avoid building Linux kernel modules from sources (on target host) due to dependency on the kernel version. AFAIK one has to build them after changing Linux kernel.
- some form of libGL - as a better interface to corresponding kernel modules
- X11-related modules - as an interface to corresponding libGL for X11 Applications.
Aside of building kernel modules Virtualbox installer provides a bulk of
VBoxOGL*.solibraries together with the X11-related shared libraries:/usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so and /usr/lib/xorg/modules/drivers/vboxvideo_drv.so. Only the X11 libs are exposed and provide a way to access VBoxOGL_: when they are loaded they only bend calls into the previously available system OpenGL (e.g. Gallium) to go via the Virtualbox's libGL (VBoxOGL_.so).@porst17 IMHO it is due to such a hack those X11 modules are required on both client AND server sides in our case of client<->server communication via unix socket.
Moreover the exposed
vboxvideo_drv.sois just a symbolic link to one of
VBoxGuestAdditions/vboxvideo_drv_{13,14,15,16,17,18,19,70,71,110,111,112,113,114,115,116,117}.sowhich is created by installation script (if it detects X11 server installed on the target host).Nvidia-installer also builds kernel modules but it is entirely different to VBGA since it actually replaces previously installed OpenGl MESA libraries with its own bulk libraries (e.g.
/usr/lib/lib{GL,EGL,GLES}*). It also provides proper X11 modules/usr/lib/xorg/modules/{libwfb.so,drivers/nvidia_drv.so,extensions/libglx.so}.@porst17 I am not sure whether those nvidia X11 modules are actually required for the client side.
In the case of client-server X11 communication via unix socket both client and server parts should be identical.
- added a commit that references this issue
on Jun 11, 2016 Initial work on this happening: https://lists.freedesktop.org/archives/xdg-app/2017-February/000534.html
This is very good news! I was also thinking about how libglvnd could help with the GL driver issues.
Now we need all GL driver vendors to actually use libglvnd. So far, the VirtualBox source tree does not have any traces of libglvnd. Their Guest Additions also use some weird mechanism that hooks into executables somehow to get GL working.
In any case, does this mean we would need a flatpak runtime for each version of each driver?
Well, technically things still work without libglvnd. You just have the extension ship a complete libgl.so. However, such a driver will be less powerful. I.e. it can't du prime-like multi-driver setups.
Yeah, we need a driver for each version. They are pretty small wrappers though.
- added a commit that references this issue
on Apr 29, 2017 - added a commit that references this issue
on Mar 1, 2023 - added 2 commits that reference this issue
on Mar 20, 2023 - added a commit that references this issue
on Nov 14, 2023 - added a commit that references this issue
on Jan 2, 2025
From @porst17 on June 17, 2015 16:35
I am on a VirtualBox VM with Ubuntu 14.04, guest additions installed (including drivers for 3d).
gives
This means
glxgearsis using the Chromium graphics driver for 3D provided by VirtualBox (ignore the warnings and the two libGL errors for now, they are a VirtualBox feature; all that counts are theGL_RENDERER,GL_VERSIONandGL_VENDORstrings).However, if I run
I get
which means that the Mesa Gallium driver is used instead of the VirtualBox Chromium driver, i.e. we only have software rendering.
Copied from original issue: alexlarsson/xdg-app#80