hansdegoede | Entries tagged with mesa

In this blog post I promised I would get back to people who want to use the nvidia driver on an optimus laptop.

The set of xserver patches I blogged about last time have landed upstream and in Fedora 25 (in xorg-x11-server 1.19.0-3 and newer), allowing the nvidia driver packages to drop a xorg.conf snippet which will make the driver atuomatically work on optimus setups.

The negativo17.org nvidia packages now are using this, so if you install these, then the nvidia driver should just work on your laptop.

Note that you should only install these drivers if you actually have a supported (new enough) nvidia GPU. These drivers replace the libGL implementation, so installing them on a system without a nvidia GPU will cause things to break. This will be fixed soon by switching to libglvnd as the official libGL provider and having both mesa and the nvidia driver provide "plugins" for libglvnd. I've actually just completed building a new enough libglvnd + libglvnd enabled mesa for rawhide, so rawhide users will have libglvnd starting tomorrow.

Recently I've been working on improving hybrid graphics support for the upcoming Fedora 25 release. Although Fedora 25 Workstation will use Wayland by default for its GNOME 3 desktop, my work has been on hybrid gfx support under X11 (Xorg) as GNOME 3 on Wayland does not yet support hybrid gfx,

So no Wayland, still there are a lot of noticable hybrid gfx support and users of laptops with hybrid gfx using the open-source drivers should have a much smoother userexperience then before. Here is an (incomplete) list of generic improvements:

Fix the discrete GPU not suspending after using an external monitor, halving laptop battery life

xrandr --listproviders no longer shows 3 devices instead of 2 on laptops with 2 GPUs

Hardware cursor support when both GPUs have active video outputs, previously X would fallback to software cursor rendering in this case which would typically lead to a flickering, or entirely invisible cursor at the top of the screen

Besides this a lot of work has been done on fixing hybrid gfx issues in the modesetting driver, this is important since with Fedora we use the modesetting driver on Skylake and newer Intel integrated gfx as well as on Maxwell and newer Nvidia discrete GPUs, the following issues have been fixed in the modesetting driver (and thus on laptops with a Skylake CPU and/or a Maxwell or newer GPU):

Hide HW cursor on init, this fixes 2 cursors showing on some setups

Make the modesetting driver support DRI_PRIME=1 render offloading when the secondary GPU is using the modesetting driver

Fix misrendering (tiled vs linear) when using DRI_PRIME=1 render offloading and the primary GPU is using the modesetting driver

Fix GL apps running at 1 fps when shown on a video-output of the secondary GPU and the primary GPU is using the modesetting driver

Fix secondary GPU video output partial screen updates (part of the screen showing a previous frame) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

Fix secondary GPU video output updates lagging (or sometimes the last frame simply not being shown at all because no further rendering is happening) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

Note coming Thursday (November 3th) we're having a Fedora Better Switchable Graphics Test Day, if you have a laptop with hybrid gfx please join us to help further improving hybrid gfx support.

All modern laptops have a gpu integrated into their processor (the igpu), some models also have a more powerful dedicated gpu (dgpu), this is called switchable graphics.

By default all apps will run on the more energy efficient igpu and the OS can choose to switch to the dgpu when more gpu-power is necessary, trading battery time for graphics performance. On most laptops the default gpu can be changed to the dgpu so that everything will always run on the dgpu.

Linux support for switchable graphics currently is not very good. E.g. on many laptops some of the external connectors are only connected to the dgpu and to be able to use those external connectors without issues users need to change the default gpu to the dgpu, resulting in a hot running laptop and the battery draining much faster.

So I will be working on improving switchable graphics support under Linux, allowing the igpu to be used as default, allowing maximum batter life, while keeping everthing working normally. Specifically the following should all work: external outputs, suspend / resume (including suspend/resume with external monitors connected / while docked) and suspending the dgpu when not used.

Some fixes for this have already landed in Fedora 24, if you've a laptop with switchable graphics, please give Fedora 24 a try. Make sure you've all updates installed, and that you're running a 4.6.x kernel (from updates-testing). Then everything should just work, specifically recently I've fixed several issues with external connectors which are only connected to the dgpu, including the dgpu not suspending after a monitor is unplugged from the external connector.

If you're still having issues using Fedora 24 (with the default open source drivers) on a laptop with switchable graphics, please file a bug and put me in the Cc, or if you already have a bug open, just put me in the Cc.

One known issue is that plymouth (the boot splash screen) in Fedora 24 does not Work well with switchable-graphics, in some cases you may
get a black screen instead of the boot splash until the graphical login manager shows. This is esp. a problem if you've a crypted disk, because the dialog asking for the disk-crypt password will not show. You can press ESC to drop to text mode as a workaround. This is fixed in the Rawhide / Fedora 25 plymouth packages, but the changes are too invasive for an update. An alternative workaround is manually installing the F25 plymouth on F24.

A secondary goal of my work on this is to allow people to run graphically demanding programs on the dgpu by starting them with "DRI_PRIME=1 program", note that since we do not support dynamic reclocking of nvidia GPUs this will not always result in a performance improvement. Again if you're using this and it does not work properly, please file a bug and put me in the Cc.

As explained in my reaction to Alexey Kuznetsov's Fedora Game must have posts maniadrive currently is packaged for Fedora, but unfortunately not usable when using opensource graphics drivers due to several regressions in mesa.

The regression (from working to crash) for intel graphics has already been fixed by upstream after I spend a day tracking down the commit causing it, see this bug.

However on r300 / r400 based cards it still doesn't work, even when using upstream git. This was beginning to annoy me so I 've spend the last 2 days tracking down the 2 distinct regressions in recent mesa:

Wrong rendering with current git (and with Fedora's packages because those have the r300 part updated to a recent git snapshot for rs480 support).
Maniadrive being slow with mesa >= 7.0 (official release, clean build).

And I managed to fix both :)

The wrong rendering is caused by the second chunk of this commit. If one reverts the second chunk of this commit, then everything gets properly rendered.
The slowness problem is caused by tnl/t_vp_build.c generating vertex programs which use 14 temp variables, and the r300 has exactly 14 temp registers (according to the current driver). This becomes a problem because:

Certain ARB vertex instructions are emulated on the r300, and the emulation code needs a temp register too.
Even those vertex programs which do not use the troublesome ARB vertex instructions will not work because there is an of by one bug in the check if there are enough registers.

I have a patch which fixes the t_vp_build.c code to not require more temp registers then it actually needs, by allocating them only when needed and freeing them asap. It takes 2 of the number of temp registers needed by the
generated code in the case of maniadrive, making maniadrive work even with the off by one bug still present in the r300 code.

Of course I've also written a patch for the off by one error. Both issues have been report in both Fedora's bugzilla and upstream.

During the investigation of this I've found out that maniadrive most likely also is broken on r200 cards, but no worry my patches should fix it there too :)

I've also done a scratch build of mesa, with all 3 patches (1 for intel, 2 for radeons) incorporated for your downloading pleasure. For good measure I've also thrown in this commit from upstream, which fixes 3D on Radeon x700 SE cards, and a patch to make mesa work on Intel E7221 equipped boards. Changelog:

Fri Dec 28 2007 Hans de Goede <[email protected]> 7.0.1-7.fc8.1
"Experimental" version by Hans de Goede <[email protected]> to test some bugfixes, not an official Fedora mesa package
Fix maniadrive from crashing on intel graphics (bug 423701)
Fix maniadrive slowness and wrong rendering on r300 and r200 cards (bug 304551)
Fix 3D on ATI x700 SE cards
Support intel e7221 (bz 425790)

Please grab and test this improved mesa version (click on the build for your arch then scroll down to get download links). Notice that this will only be available for about a week as koji deletes scratchbuilds after that. Feedback much appreciated, I hope that the Fedora mesa maintainers will pick up this bunch of patches and do an F-8 update with them included, I'm sure it will help if I can tell them quite a few people already tested this with positive results.

Hans de Goede

Entries tagged with mesa

negativo17.org nvidia packages should now work out of the box on optimus setups

Switchable / Hybrid Graphics support in Fedora 25

Improving Linux Switchable Graphics support

Time for some mesa hacking

Profile

May 2025

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags