Force use of software rendering #214
Conversation
|
There's also |
|
Using only With vulkan disabled also, it takes half the time of the previous example: $ env GDK_DEBUG="gl-disable vulkan-disable" LIBGL_ALWAYS_SOFTWARE=1 zenity --question --title title --text text --timeout 1
Gsk-Message: Failed to realize renderer of type 'GskNglRenderer' for surface 'GdkX11Toplevel': GL support disabled via GDK_DEBUG
Gsk-Message: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Toplevel': GL support disabled via GDK_DEBUG
Gsk-Message: Failed to realize renderer of type 'GskVulkanRenderer' for surface 'GdkX11Toplevel': Vulkan support disabled via GDK_DEBUG@rustybird, from the thread you shared, I found the following comment:
Gnome developer says that setting the renderer to
So... maybe instead of fighting Gnome programs, like the default templates changed to Xfce, change to another tool, which I do not know if there is anything suitable that is a GUI with few dependencies that doesn't require hardware acceleration. I know it will not be good UX wise if we switch to |
|
Agreed that it would be good to find an alternative to zenity. Also because the Debian build of it is so bloated (from WebKit support) that it's not even included in the minimal Debian template. But the bad performance of modern GTK programs still seems like an important thing to address too. The only way I can see is switching to Cairo, even if it's not future-proof and potentially breaks some programs. (Which ones though?) Maybe it could be done through an easier to override mechanism? E.g. as a |
Ah wait, that might also interact with sys-gui-gpu 🤔 |
Indeed Zenity should not be used.
The proper and long-term solution is to expose the GPU to guests in a secure way. Everything else is a workaround until secure GPU acceleration can be implemented. Unfortunately, GPU security has lagged behind CPU security, but this must be fixed on the GPU side. Software rendering is a fallback for a reason. In the short term, switching to Cairo is one option. I would be much more confortable doing so on a per-program basis than system-wide, though. Otherwise there will be programs that break for no apparent reason.
@marmarta do you have an opinion here? |
|
Just to get an idea of all components that uses zenity and how many times it appears per file: $ rg -c -e "zenity -" -e "'zenity', '-" -e '"zenity", "-'
qubes-app-linux-split-gpg/qubes.Gpg.service:1
qubes-gui-daemon/gui-daemon/xside.c:1
qubes-app-linux-split-gpg2/splitgpg2/__init__.py:1
qubes-core-agent-linux/qubes-rpc/qubes.SelectFile:1
qubes-core-agent-linux/qubes-rpc/qvm-copy-to-vm.gnome:1
qubes-core-agent-linux/qubes-rpc/thunar/qvm-actions.sh:3
qubes-core-agent-linux/qubes-rpc/vm-file-editor.c:1
qubes-core-agent-linux/qubes-rpc/qvm-open-in-vm:1
qubes-core-agent-linux/qubes-rpc/qubes.SelectDirectory:1
qubes-core-agent-linux/qubes-rpc/gui-fatal.c:1
qubes-core-agent-linux/debian/changelog:1
qubes-core-agent-linux/package-managers/qubes-download-dom0-updates.sh:2
qubes-core-admin-linux/file-copy-vm/qfile-dom0-agent.c:1
qubes-core-admin-linux/dom0-updates/qubes-dom0-update:2
qubes-core-admin/qubes/tests/integ/basic.py:2
qubes-app-linux-img-converter/qvm-convert-img.gnome:1
qubes-app-linux-img-converter/qimg-convert-client:1
qubes-app-linux-img-converter/qvm-convert-img-gnome:1
qubes-app-linux-pdf-converter/qvm-convert-pdf.gnome:1
qubes-core-qrexec/daemon/qrexec-daemon.c:1 |
I'm fine with this solution, if there is an easy opt-out. Nobody shown any broken apps by this approach yet, so until that happens, I would ignore this downside as it looks purely theoretical. As for the opt-out - maybe use qvm-service? that would allow easily doing it per-qube. And on the global scale you can always place some later file in /etc/profile.d (or whichever other dir is chosen), but it needs to be documented somewhere. |
| @@ -1 +1,5 @@ | |||
| export DISPLAY=:0 _JAVA_AWT_WM_NONREPARENTING=1 | |||
| if ! test -f /var/run/qubes-service/gpu-accel; then | |||
There was a problem hiding this comment.
I'd prefer a name like software-rendering or similar, instead of gpu-accel. The latter may suggest enabling it will actually get you GPU acceleration, which is not really the case.
There was a problem hiding this comment.
Sure. I am searching where default services are set to enable software-rendering by default... Until I find them, I will commit with the same logic: ! test -f /var/run/qubes-service/hardware-rendering.
There was a problem hiding this comment.
Found, vm-systemd/qubes-sysinit.sh
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024062200-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024062115-4.3&flavor=update
Failed tests8 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/103633#dependencies 6 fixed
Unstable tests
|
ben-grande
force-pushed
the
egl
branch
3 times, most recently
from
25a4e84 to
8ba08ec
Compare
| @@ -1,2 +1,5 @@ | |||
| setenv DISPLAY ":0" | |||
| setenv _JAVA_AWT_WM_NONREPARENTING "1" | |||
| setenv DISPLAY ":0" _JAVA_AWT_WM_NONREPARENTING "1" | |||
There was a problem hiding this comment.
I don't think you can set multiple variables with a single setenv call...
There was a problem hiding this comment.
$ setenv test "abc" test2 "def"
setenv: Too many arguments.
| setenv _JAVA_AWT_WM_NONREPARENTING "1" | ||
| setenv DISPLAY ":0" _JAVA_AWT_WM_NONREPARENTING "1" | ||
| if ( -f /var/run/qubes-service/software-rendering ) | ||
| setenv GSK_RENDERER "cairo" GDK_DEBUG "gl-disable vulkan-disable" \ |
Hardware acceleration can be enabled by setting the qvm-service gpu-accel to a truthy value. Fixes: QubesOS/qubes-issues#9268 For: QubesOS/qubes-core-admin-client#294
Fixes: QubesOS/qubes-issues#9268 For: QubesOS/qubes-core-admin-client#294 For: QubesOS/qubes-gui-agent-linux#214 (cherry picked from commit cde71d9)
For: QubesOS/qubes-issues#9268 For: QubesOS/qubes-gui-agent-linux#214 (cherry picked from commit 8639ee4)
Fixes: QubesOS/qubes-issues#9268
Awaiting reply to QubesOS/qubes-issues#9268 (comment)