Disable Acceleration to Fix GPU Issues

[entr0py]

I've posted several seemingly disparate issues regarding crashes:

OpenGL in Dom0 Needed?
Unable to Resume VMs after KWin Crash
LibreOffice Base GUI Performance Issues in Qubes

The crashes would occur at random times and exhibit as ring0 lockups causing KWin to crash; complete machine resets and freezes; individual vm's losing gui with guid outdated errors, laggy refreshes, you name it. As much as I love Qubes, I've been a nervous wreck using it, basically pressing Ctrl-S after every phrase.

The problem was narrowed down to my GPU, a Radeon HD7950. The plan was just to tough it out until transitioning to an Intel GPU was possible. However, 3.1 rc3 has increased the frequency of crashes from 1 every 2-3 days to 1 every couple of hours.

Initially, I thought changing Desktop Effects from OpenGL to XRender would solve the issue but that only disables acceleration for Desktop Effects. To disable acceleration for X completely, you need to modify your xorg.conf. Since Qubes doesn't implement acceleration in AppVMs, there's no reason to leave it on.

For 'radeon' driver; in dom0, add this to your xorg.conf:
(or most likely you won't have one, so touch /etc/X11/xorg.conf.d/50-video.conf)

Section "Device"

Identifier "card0"
Driver "radeon"
Option "NoAccel" "True"

EndSection

All my issues are gone! Hope this helps someone.

[Cube]

Thanks, that's very helpful. I'll give it a try. At the moment I think Qubes is really an Intel GPU only OS which is pretty limiting. I've seen too many issues on AMD and Nvidia. I'd prefer either leaving that functionality entirely out or improve it (general Linus distro's have no issues on the same hardware).

I have a laptop with both Intel and AMD GPU's and have to be careful not to invoke the AMD, maybe with this fix it'll work better,

[Eric Shelton]

On Saturday, February 27, 2016 at 7:40:16 AM UTC-5, Cube wrote:

On Thursday, February 25, 2016 at 8:56:59 AM UTC-8, entr0py wrote:

I've posted several seemingly disparate issues regarding crashes:

OpenGL in Dom0 Needed?
Unable to Resume VMs after KWin Crash
LibreOffice Base GUI Performance Issues in Qubes

The crashes would occur at random times and exhibit as ring0 lockups causing KWin to crash; complete machine resets and freezes; individual vm's losing gui with guid outdated errors, laggy refreshes, you name it. As much as I love Qubes, I've been a nervous wreck using it, basically pressing Ctrl-S after every phrase.

The problem was narrowed down to my GPU, a Radeon HD7950. The plan was just to tough it out until transitioning to an Intel GPU was possible. However, 3.1 rc3 has increased the frequency of crashes from 1 every 2-3 days to 1 every couple of hours.

Initially, I thought changing Desktop Effects from OpenGL to XRender would solve the issue but that only disables acceleration for Desktop Effects. To disable acceleration for X completely, you need to modify your xorg.conf. Since Qubes doesn't implement acceleration in AppVMs, there's no reason to leave it on.

For 'radeon' driver; in dom0, add this to your xorg.conf:
(or most likely you won't have one, so touch /etc/X11/xorg.conf.d/50-video.conf)

Section "Device"

Identifier "card0"
Driver "radeon"
Option "NoAccel" "True"

EndSection

All my issues are gone! Hope this helps someone.

Thanks, that's very helpful. I'll give it a try. At the moment I think Qubes is really an Intel GPU only OS which is pretty limiting.

That is probably a fair assessment.  See https://groups.google.com/d/msg/qubes-devel/mvZBIUuyjv0/HSgrJZzAAAAJ  The core dev team has their hands full, does an amazing amount of work with the resources at their disposal, and it is understandable that this is not a priority for them - there is already enough new development work in the current roadmap.

I think there was also a period where Qubes did not really update graphics support for a little while - a consequence of dom0 hanging back on Fedora 20 (due to a technical issue that could not be easily addressed).  I suspect the experience was even worse for non-Intel GPUs during that time.

My experience with Qubes on a non-Intel GPU was with an NVIDIA GPU.  The main problems I encountered were: (1) the nouveau driver is/was pretty poor, and screen blanking caused problems, and (2) battery life was significantly reduced by using the discrete GPU.  By moving to the Intel GPU, everything just worked, worked well enough, and used less battery.

I've seen too many issues on AMD and Nvidia. I'd prefer either leaving that functionality entirely out or improve it (general Linus distro's have no issues on the same hardware).

It would be great if AMD and NVIDIA adapters would "just work."  But NVIDIA and AMD - particularly whatever products are "current generation" - have always been difficult to deal with on Linux.  Is the situation with their GPUs really all that much better than it was 10 or 15 years ago?  It just seems like a slightly different set of bandaids, special configuration options, and closed source driver issues every year.  This is mainly a result of the difference in attitudes between the GPU vendors towards Linux generally, and Xen specifically: Intel has been actively engaged with the Linux and Xen communities, AMD has been OK on releasing enough specs for non-cutting edge GPUs that allow OK open source drivers to be written, and NVIDIA seems to be (by many reports) actively frustrating open source efforts on Linux, Xen, and KVM (see https://www.reddit.com/r/linux/comments/2twq7q/nvidia_apparently_pulls_some_shady_shit_to_do/).

If it has been solved on Linux distros generally, it would seem to be solvable on Qubes.  However, I think that resolution of non-Intel GPU issues - now and for the foreseeable future - will have to be a community effort.  If someone steps up to own it (or part of it, such as AMD GPUs), and implement whatever is believed to have solved things on other Linux distros, I have no doubt that it would get incorporated into Qubes.  Given the general level of expertise within the Qubes user community, you would think there would be more community development effort happening in general...

Otherwise, I believe things are indeed going to become more and more slanted in favor of Intel GPUs on Qubes, and maybe that's OK.  Intel is the only one of the three GPU vendors working to make GPU virtualization/sharing a reality (https://01.org/igvt-g), and Qubes is likely poised to be the first notebook-friendly OS to fully exploit this feature.  It sounds like a great feature, an dthere is going to be no way to replicate it on AMD or NVIDIA* GPUs.

* Actually, there is a closed-source effort from NVIDIA for GPU sharing on the XenServer commercial product, using their incredibly expensive GRID GPUs.  http://www.nvidia.com/object/xendesktop-vgpu.html  However, I'm not sure it offers everything Intel GVT will, and I doubt NVIDIA is going to help integrate it into Qubes.

Eric

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Feb 27, 2016 at 09:47:02AM -0800, Eric Shelton wrote:
> On Saturday, February 27, 2016 at 7:40:16 AM UTC-5, Cube wrote:
> >
> >
> >
> > On Thursday, February 25, 2016 at 8:56:59 AM UTC-8, entr0py wrote:
> >>
> >> I've posted several seemingly disparate issues regarding crashes:
> >>
> >> OpenGL in Dom0 Needed?

> >> <https://groups.google.com/forum/#%21topic/qubes-users/3v5-lGKUCPs>

> >> Unable to Resume VMs after KWin Crash

> >> <https://groups.google.com/forum/#!topic/qubes-users/IloTq2TW1q0>

> >> LibreOffice Base GUI Performance Issues in Qubes

> >> <https://groups.google.com/forum/#!topic/qubes-users/coOC18sMnmA>

Exactly, I couldn't describe the situation better. Thanks Eric!

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW0eWeAAoJENuP0xzK19csv0kH/1pa1FBge93p8dZ5co6vId39
QmDFNA38HjoJ28GzrI8oc46qcS3UGvJyJsol6NAyYUd3QTXA7b7rr27qWXC9A7hZ
xn1fHzS1YPhsXo8SYljsYkL6walErHnlvvTZqMVynfqLcfNOO3Nq/qsS2r7LDB2O
EylZKBfEa7CwQ0wePtpfOo+MFFZ/jpwpUdUGlN6d13XEU8JrIkYvyytYomPik4Lr
F4aiOXQsa+WN1diOEFqPJ3iWxUYySAx9v0IMDn8qPBy+OCTvD77a1ARFVzyFKtfp
RmMwTggtN6suT6VQ/b4B8JaNB4Xo6aEEBE6NH/f9vqIoHErUnRNxy0W6HRjAA5U=
=cuXk
-----END PGP SIGNATURE-----

[entr0py]

On Saturday, February 27, 2016 at 12:40:16 PM UTC, Cube wrote:

On Thursday, February 25, 2016 at 8:56:59 AM UTC-8, entr0py wrote:

For 'radeon' driver; in dom0, add this to your xorg.conf:
(or most likely you won't have one, so touch /etc/X11/xorg.conf.d/50-video.conf)

Section "Device"

Identifier "card0"
Driver "radeon"
Option "NoAccel" "True"

EndSection

Thanks, that's very helpful. I'll give it a try.

 
You can probably test by using kernel parameters at boot: radeon.noaccel=1 or nouveau.noaccel=1 depending on your card.

Option "NoAccel" "True" should be echoed without errors in /var/log/Xorg.0.log

To confirm, glxinfo | grep OpenGL should change
from
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
to
OpenGL renderer string: Gallium 0.4 on llvmpipe
or similar.

[entr0py]

On Saturday, February 27, 2016 at 5:47:02 PM UTC, Eric Shelton wrote:

That is probably a fair assessment.  See https://groups.google.com/d/msg/qubes-devel/mvZBIUuyjv0/HSgrJZzAAAAJ  The core dev team has their hands full, does an amazing amount of work with the resources at their disposal, and it is understandable that this is not a priority for them - there is already enough new development work in the current roadmap.

I think there was also a period where Qubes did not really update graphics support for a little while - a consequence of dom0 hanging back on Fedora 20 (due to a technical issue that could not be easily addressed).  I suspect the experience was even worse for non-Intel GPUs during that time.

My experience with Qubes on a non-Intel GPU was with an NVIDIA GPU.  The main problems I encountered were: (1) the nouveau driver is/was pretty poor, and screen blanking caused problems, and (2) battery life was significantly reduced by using the discrete GPU.  By moving to the Intel GPU, everything just worked, worked well enough, and used less battery.

I've seen too many issues on AMD and Nvidia. I'd prefer either leaving that functionality entirely out or improve it (general Linus distro's have no issues on the same hardware).

It would be great if AMD and NVIDIA adapters would "just work."  But NVIDIA and AMD - particularly whatever products are "current generation" - have always been difficult to deal with on Linux.  Is the situation with their GPUs really all that much better than it was 10 or 15 years ago?  It just seems like a slightly different set of bandaids, special configuration options, and closed source driver issues every year.  This is mainly a result of the difference in attitudes between the GPU vendors towards Linux generally, and Xen specifically: Intel has been actively engaged with the Linux and Xen communities, AMD has been OK on releasing enough specs for non-cutting edge GPUs that allow OK open source drivers to be written, and NVIDIA seems to be (by many reports) actively frustrating open source efforts on Linux, Xen, and KVM (see https://www.reddit.com/r/linux/comments/2twq7q/nvidia_apparently_pulls_some_shady_shit_to_do/).

If it has been solved on Linux distros generally, it would seem to be solvable on Qubes.  However, I think that resolution of non-Intel GPU issues - now and for the foreseeable future - will have to be a community effort.  If someone steps up to own it (or part of it, such as AMD GPUs), and implement whatever is believed to have solved things on other Linux distros, I have no doubt that it would get incorporated into Qubes.  Given the general level of expertise within the Qubes user community, you would think there would be more community development effort happening in general...

Otherwise, I believe things are indeed going to become more and more slanted in favor of Intel GPUs on Qubes, and maybe that's OK.  Intel is the only one of the three GPU vendors working to make GPU virtualization/sharing a reality (https://01.org/igvt-g), and Qubes is likely poised to be the first notebook-friendly OS to fully exploit this feature.  It sounds like a great feature, an dthere is going to be no way to replicate it on AMD or NVIDIA* GPUs.

* Actually, there is a closed-source effort from NVIDIA for GPU sharing on the XenServer commercial product, using their incredibly expensive GRID GPUs.  http://www.nvidia.com/object/xendesktop-vgpu.html  However, I'm not sure it offers everything Intel GVT will, and I doubt NVIDIA is going to help integrate it into Qubes.

Eric

Given the ubiquity of Intel GPUs and the workload involved in troubleshooting NVIDIA/AMD issues, I agree also that the dev's priorities should be focused elsewhere. I have an edge situation with a monitor / motherboard combo that requires the outputs from my graphics card.

Why not disable hardware acceleration by default? Compatibility won't be guaranteed in the near future and Qubes doesn't make use of it anyway. Any Qubes user with the wherewithal to implement VGA passthrough will certainly not have any trouble re-enabling acceleration. This change could potentially be of great benefit to newcomers or trial users.

[raah...@gmail.com]

I run qubes with an nvidia 650 ti card. I raise my opengl to 3.1 and put full screen repaints to avoid tearing which is common in linux and everything runs absolutely great.

In my experience if your card is fairly new you might have problems in linux in general. Hardware for linux always gets better with age lol.(which is probably why intel drivers work good for most people) but otherwise the open source drivers for linux seem to be improving every year. (and getting less secure at the same time i might add lmao)

[Drew White]

On Friday, 26 February 2016 03:56:59 UTC+11, entr0py wrote:

For 'radeon' driver; in dom0, add this to your xorg.conf:
(or most likely you won't have one, so touch /etc/X11/xorg.conf.d/50-video.conf)

Section "Device"

Identifier "card0"
Driver "radeon"
Option "NoAccel" "True"

EndSection

All my issues are gone! Hope this helps someone.

This resolution did not fix the problem for me.