Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

Writing on their personal blog, Jason Ekstrand from the Intel Mesa team has written up some information on what they've been doing to improve the Intel drivers on Linux. What they're talking about isn't exactly new, since the fixes are already in Mesa but it's nice to get some information about how they came across the issues and what they did to solve them.

Regardless of your feelings towards Wine, DXVK, Steam Play and so on, no one can ignore the benefits they bring to the people actually working on the drivers. Giving them so many more ways to test and push Linux graphics drivers is a good thing, as it means we can end up with much better drivers for all sorts of workloads (not just gaming!).

Ekstrand noted two specific games in the blog post, with Skyrim Special Edition originally performing like a slide-show. After some debugging with the help of RenderDoc, Ekstrand was able to find a certain draw call that was causing issues which resulted in this patch bringing the game up to a playable framerate.

They go on to talk a little about Batman: Arkham City as well which was causing GPU hangs with DXVK, after some investigation they patched the driver some more to optimize it and improve performance. The ending remarks are also nice to read:

So what's the moral of the story?  It's not that bad shaders or spilling is the root of all performance problems.  (I could just as easily tell you stories of badly placed HiZ resolves.)  It's that sometimes big performance problems are caused by small things (that doesn't mean they're easy to find!).  Also, that we (the developers on the Intel Mesa team) care about Linux gamers and are hard at work trying to make our open-source Vulkan and OpenGL drivers the best they can be.

Really good to see driver developers get stuck in to work on improving performance. You can see the whole post here, interesting stuff!

Article taken from GamingOnLinux.com.
Tags: Drivers, Intel
26 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
19 comments

legluondunet Sep 19, 2018
Valve launched a dynamic on the Linux platform that others actors can not ignore. Good to see that.
danniello Sep 19, 2018
Sorry for my ignorance - I'm not developer but something went very wrong with game development and/or graphics SDK development (I mean everyone: OpenGL, DirectX, Vulkan) and/or GPU drivers development.

Every new AAA game means NEW nVidia/AMD driver with special workarounds for this particular game. Why?! In theory it shouldn't be needed! It is normal for every AAA premiere on Windows side. It looks like similar workarounds now are needed for Linux drivers - even when it is started via wine/proton...

Probably the same situation is on console side - every "big" title require download/install new console firmware (so in fact - new system probably with dedicated workarounds)...
RussianNeuroMancer Sep 19, 2018
They've not been ignoring anything.
You forgot BayTrail/CherryTrail SoC drivers fiasco - as soon as management pull the plug for Atom series, almost all Intel's own Atom development efforts stopped, including Windows (no drivers updates since year 2016) and Linux drivers (left unusable; devboards was tested and supported, tablets and laptops - not). Only occasional GPU driver fixes left, and not as fast as one would expect. Couple of years later BayTrail/CherryTrail devices gets usable, but only because external (and some internal developers polished drivers in their own free time.

So, Intel do ignore hardware they intentionally left behind, and they ignore it on Linux too. And I not even talking about (drivers for) boards and IoT platforms they introduce, just to kill it year of two later.

On topic: BayTrail Vulkan drivers allow to play Talos Principle with Vulkan API and 20+ fps even on low-end laptop with Z3735F, which is kind of unexpected from unfinished experimental driver (BayTrail share GPU with Ivybridge). Running same game in OpenGL mode produce empty skybox with few objects, so seems like OpenGL implementation for BayTrail is more buggy than Vulkan implementation. It's will be interesting to see how DXVK would perform on such low-end devices.
Leopard Sep 19, 2018
Linux drivers are turning into something spectacular on Vulkan wise.

Not just native Vulkan wise , DXVK also helps many not on the spot corners too.
edmondo Sep 19, 2018
Jason Ekstrand is legendary level. Incredible amount of work from him for NIR and Vulkan in Mesa.

@liamdawe another one to interview, if not already done ;)
m2mg2 Sep 19, 2018
They've not been ignoring anything.
You forgot BayTrail/CherryTrail SoC drivers fiasco - as soon as management pull the plug for Atom series, almost all Intel's own Atom development efforts stopped, including Windows (no drivers updates since year 2016) and Linux drivers (left unusable; devboards was tested and supported, tablets and laptops - not). Only occasional GPU driver fixes left, and not as fast as one would expect. Couple of years later BayTrail/CherryTrail devices gets usable, but only because external (and some internal developers polished drivers in their own free time.

So, Intel do ignore hardware they intentionally left behind, and they ignore it on Linux too. And I not even talking about (drivers for) boards and IoT platforms they introduce, just to kill it year of two later.

On topic: BayTrail Vulkan drivers allow to play Talos Principle with Vulkan API and 20+ fps even on low-end laptop with Z3735F, which is kind of unexpected from unfinished experimental driver (BayTrail share GPU with Ivybridge). Running same game in OpenGL mode produce empty skybox with few objects, so seems like OpenGL implementation for BayTrail is more buggy than Vulkan implementation. It's will be interesting to see how DXVK would perform on such low-end devices.

There is an intel graphics driver bug that affects my laptop that has been there since fedora 27. I have to use the Fedora 26 kernel in Fedora 28 or my screen flickers constantly. I have had so many issues like this with intel graphics. They should just work, but whatever machine I'm working with almost always happens to be affected by some bug where the intel graphics driver doesn't work right. My laptop isn't even that old, it's a Latitude 5480.
Leopard Sep 19, 2018
They've not been ignoring anything.
You forgot BayTrail/CherryTrail SoC drivers fiasco - as soon as management pull the plug for Atom series, almost all Intel's own Atom development efforts stopped, including Windows (no drivers updates since year 2016) and Linux drivers (left unusable; devboards was tested and supported, tablets and laptops - not). Only occasional GPU driver fixes left, and not as fast as one would expect. Couple of years later BayTrail/CherryTrail devices gets usable, but only because external (and some internal developers polished drivers in their own free time.

So, Intel do ignore hardware they intentionally left behind, and they ignore it on Linux too. And I not even talking about (drivers for) boards and IoT platforms they introduce, just to kill it year of two later.

On topic: BayTrail Vulkan drivers allow to play Talos Principle with Vulkan API and 20+ fps even on low-end laptop with Z3735F, which is kind of unexpected from unfinished experimental driver (BayTrail share GPU with Ivybridge). Running same game in OpenGL mode produce empty skybox with few objects, so seems like OpenGL implementation for BayTrail is more buggy than Vulkan implementation. It's will be interesting to see how DXVK would perform on such low-end devices.

There is an intel graphics driver bug that affects my laptop that has been there since fedora 27. I have to use the Fedora 26 kernel in Fedora 28 or my screen flickers constantly. I have had so many issues like this with intel graphics. They should just work, but whatever machine I'm working with almost always happens to be affected by some bug where the intel graphics driver doesn't work right. My laptop isn't even that old, it's a Latitude 5480.

By flicker , you mean tearing?

If it is , you can change your accel to UXA

https://wiki.archlinux.org/index.php/intel_graphics#SNA_issues
Purple Library Guy Sep 19, 2018
I hope that helps explain it a little bit.
Dunno about anyone else, but it was useful as all get out to me.
RussianNeuroMancer Sep 20, 2018
They've not been ignoring anything.
You forgot BayTrail/CherryTrail SoC drivers fiasco - as soon as management pull the plug for Atom series, almost all Intel's own Atom development efforts stopped, including Windows (no drivers updates since year 2016) and Linux drivers (left unusable; devboards was tested and supported, tablets and laptops - not). Only occasional GPU driver fixes left, and not as fast as one would expect. Couple of years later BayTrail/CherryTrail devices gets usable, but only because external (and some internal developers polished drivers in their own free time.

So, Intel do ignore hardware they intentionally left behind, and they ignore it on Linux too. And I not even talking about (drivers for) boards and IoT platforms they introduce, just to kill it year of two later.

On topic: BayTrail Vulkan drivers allow to play Talos Principle with Vulkan API and 20+ fps even on low-end laptop with Z3735F, which is kind of unexpected from unfinished experimental driver (BayTrail share GPU with Ivybridge). Running same game in OpenGL mode produce empty skybox with few objects, so seems like OpenGL implementation for BayTrail is more buggy than Vulkan implementation. It's will be interesting to see how DXVK would perform on such low-end devices.

There is an intel graphics driver bug that affects my laptop that has been there since fedora 27. I have to use the Fedora 26 kernel in Fedora 28 or my screen flickers constantly. I have had so many issues like this with intel graphics. They should just work, but whatever machine I'm working with almost always happens to be affected by some bug where the intel graphics driver doesn't work right. My laptop isn't even that old, it's a Latitude 5480.

By flicker , you mean tearing?

If it is , you can change your accel to UXA

https://wiki.archlinux.org/index.php/intel_graphics#SNA_issues
I pretty sure he mean "flicker". I have same issue on HP EliteBook Folio G1 on anything newer than Linux 4.15. Workaround is disabling rc6, but this kills power management, which is unacceptable for laptop, disabling rc6 is impossible with newer kernels, so stuck with 4.15 for now. This bug, of course, was reported.
m2mg2 Sep 20, 2018
They've not been ignoring anything.
You forgot BayTrail/CherryTrail SoC drivers fiasco - as soon as management pull the plug for Atom series, almost all Intel's own Atom development efforts stopped, including Windows (no drivers updates since year 2016) and Linux drivers (left unusable; devboards was tested and supported, tablets and laptops - not). Only occasional GPU driver fixes left, and not as fast as one would expect. Couple of years later BayTrail/CherryTrail devices gets usable, but only because external (and some internal developers polished drivers in their own free time.

So, Intel do ignore hardware they intentionally left behind, and they ignore it on Linux too. And I not even talking about (drivers for) boards and IoT platforms they introduce, just to kill it year of two later.

On topic: BayTrail Vulkan drivers allow to play Talos Principle with Vulkan API and 20+ fps even on low-end laptop with Z3735F, which is kind of unexpected from unfinished experimental driver (BayTrail share GPU with Ivybridge). Running same game in OpenGL mode produce empty skybox with few objects, so seems like OpenGL implementation for BayTrail is more buggy than Vulkan implementation. It's will be interesting to see how DXVK would perform on such low-end devices.

There is an intel graphics driver bug that affects my laptop that has been there since fedora 27. I have to use the Fedora 26 kernel in Fedora 28 or my screen flickers constantly. I have had so many issues like this with intel graphics. They should just work, but whatever machine I'm working with almost always happens to be affected by some bug where the intel graphics driver doesn't work right. My laptop isn't even that old, it's a Latitude 5480.

By flicker , you mean tearing?

If it is , you can change your accel to UXA

https://wiki.archlinux.org/index.php/intel_graphics#SNA_issues
I pretty sure he mean "flicker". I have same issue on HP EliteBook Folio G1 on anything newer than Linux 4.15. Workaround is disabling rc6, but this kills power management, which is unacceptable for laptop, disabling rc6 is impossible with newer kernels, so stuck with 4.15 for now. This bug, of course, was reported.

Yes, it is flickering not tearing. I saw the power management work arounds, which as you say are unacceptable. Yes it is a known bug which has been reported, acknowledged and reconfirmed many times as still being there, it just hasn't been fixed or even had a reasonable workaround available as far as I know. So I'm stuck on the F26 kernel hoping, but not confident, that it will get fixed.
johndoe Sep 20, 2018
@m2mg2 @RussianNeuroMancer

You are talking about the Intel Xorg DDX driver. This one has nothing to do with Mesa driver.

Did you guys tried the "modesetting" driver which today is integrated into Xorg and not a separate driver like Intel, Radeon, AMDGPU, etc. ?!
I use it for any Intel iGPU system and it simply works better than Intel DDX.

Section "Device"
Identifier "Modesetting" <<<< whatever
Driver "modesetting"
Option "AccelMethod" "glamor"
Option "PageFlip" "off" <<<< currently needed for Xorg 1.20.x with enabled composite
EndSection


Last edited by johndoe on 20 September 2018 at 7:11 am UTC
RussianNeuroMancer Sep 20, 2018
Did you guys tried the "modesetting" driver
Yes, because it's default.
johndoe Sep 20, 2018
Did you guys tried the "modesetting" driver
Yes, because it's default.

AND?
Whats the outcome? Does it solve your problems?


Last edited by johndoe on 20 September 2018 at 5:27 pm UTC
RussianNeuroMancer Sep 21, 2018
Whats the outcome?
Outcome described in bugreport. This bug is unrelated to DDX, issue occur on lower lewel.
johndoe Sep 21, 2018
Whats the outcome?
Outcome described in bugreport. This bug is unrelated to DDX, issue occur on lower lewel.

Ehhh, this Artikel/Blog is from 2016.
I also remember having some troubles with modesetting years ago and setting up dual-screen with it.
But these problems do not apply anymore.
With Debian Stretch (stock Xorg 1.19.2 and stock 4.9.x kernel) there should be not problems.

And to be honest I think that a Linux user should be able/learn to compile a newer Xorg server - it's really easy.
Linux gives the user ALL freedom which Windows does NOT.
This is my opinion - nothing more.
Purple Library Guy Sep 21, 2018
And to be honest I think that a Linux user should be able/learn to compile a newer Xorg server - it's really easy.
Yeah, some of us are in it to use our computer, not fiddle with it.
m2mg2 Sep 22, 2018
Whats the outcome?
Outcome described in bugreport. This bug is unrelated to DDX, issue occur on lower lewel.

Ehhh, this Artikel/Blog is from 2016.
I also remember having some troubles with modesetting years ago and setting up dual-screen with it.
But these problems do not apply anymore.
With Debian Stretch (stock Xorg 1.19.2 and stock 4.9.x kernel) there should be not problems.

And to be honest I think that a Linux user should be able/learn to compile a newer Xorg server - it's really easy.
Linux gives the user ALL freedom which Windows does NOT.
This is my opinion - nothing more.

https://bugs.freedesktop.org/show_bug.cgi?id=103229

09-14-2018 is pretty current. Compiling Xorg is not something that should be done on a normal distro, but on Linux From Scratch or something like that (Gentoo). Just compiling a small program causes dependency problems after a while. Can I compile Xorg, sure, can I compile the kernel as well, sure, do I want to spend all my time compiling all the different parts of my distro and fixing what breaks because I've got custom compiled stuff all over the place instead of using what's in the distro repo's..... no


Last edited by m2mg2 on 22 September 2018 at 1:34 am UTC
m2mg2 Sep 22, 2018
Whats the outcome?
Outcome described in bugreport. This bug is unrelated to DDX, issue occur on lower lewel.

Ehhh, this Artikel/Blog is from 2016.
I also remember having some troubles with modesetting years ago and setting up dual-screen with it.
But these problems do not apply anymore.
With Debian Stretch (stock Xorg 1.19.2 and stock 4.9.x kernel) there should be not problems.

And to be honest I think that a Linux user should be able/learn to compile a newer Xorg server - it's really easy.
Linux gives the user ALL freedom which Windows does NOT.
This is my opinion - nothing more.

My Xorg and Kernel versions both are much newer than that. 1.19.6 and 4.17
johndoe Oct 1, 2018
And to be honest I think that a Linux user should be able/learn to compile a newer Xorg server - it's really easy.
Yeah, some of us are in it to use our computer, not fiddle with it.

Agreed (sorry for beeing late).
But having the choice to alter the situation is worth it - at least for me.

@m2mg2
This is real sad, maybe put a little more pressure and point to the fact how old this issue is. That's what I occasionally do on bug trackers - it mostly helps.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.