glxgears uses software instead of hardware accellerated rendering
porst17 opened this issue · 11 comments
I am on a VirtualBox VM with Ubuntu 14.04, guest additions installed (including drivers for 3d).
$ glxgears -info
gives
libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table
OpenGL Warning: glVertexArrayRangeNV not found in mesa table
OpenGL Warning: glCombinerInputNV not found in mesa table
OpenGL Warning: glCombinerOutputNV not found in mesa table
OpenGL Warning: glCombinerParameterfNV not found in mesa table
OpenGL Warning: glCombinerParameterfvNV not found in mesa table
OpenGL Warning: glCombinerParameteriNV not found in mesa table
OpenGL Warning: glCombinerParameterivNV not found in mesa table
OpenGL Warning: glFinalCombinerInputNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glDeleteFencesNV not found in mesa table
OpenGL Warning: glFinishFenceNV not found in mesa table
OpenGL Warning: glGenFencesNV not found in mesa table
OpenGL Warning: glGetFenceivNV not found in mesa table
OpenGL Warning: glIsFenceNV not found in mesa table
OpenGL Warning: glSetFenceNV not found in mesa table
OpenGL Warning: glTestFenceNV not found in mesa table
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
GL_RENDERER = Chromium
GL_VERSION = 2.1 Chromium 1.9
GL_VENDOR = Humper
...
This means glxgears is 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 the GL_RENDERER, GL_VERSION and GL_VENDOR strings).
However, if I run
$ xdg-app run org.freedesktop.glxgears -info
I get
libGL error: pci id for fd 4: 80ee:beef, driver (null)
libGL error: unable to load driver: vboxvideo_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: vboxvideo
GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
GL_VERSION = 3.0 Mesa 10.5.5
GL_VENDOR = VMware, Inc.
...
which means that the Mesa Gallium driver is used instead of the VirtualBox Chromium driver, i.e. we only have software rendering.
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/GL
This 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.
You need at least two files in the app: the libGL.so and 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 is vboxvideo_dri.so. I don't know if additional files are needed. Since the driver supplies the libGL.so in 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, where libGL get's the instructions from to load the vboxvideo DRI 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)
A colleague of mine, @malex984, worked on hardware accelerated OpenGL for Docker containers. Maybe he can share his findings.
Oh, hardware acceleration already works for the drivers that are in the runtime, it just does not contain the vmware driver.
... but how do you ensure that the correct version of the driver is contained in the runtime? The graphics driver provides libGL.so as 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.GL extension 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.
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.
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*.so libraries 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.so is 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}.so which 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.
This issue was moved to flatpak/flatpak#1