You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!

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!

31 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more information here.
21 comments
Page: 1/3»
  Go to:

legluondunet 19 September 2018 at 12:52 pm UTC
Valve launched a dynamic on the Linux platform that others actors can not ignore. Good to see that.
mirv 19 September 2018 at 1:27 pm UTC
View PC info
  • Supporter
legluondunetValve launched a dynamic on the Linux platform that others actors can not ignore. Good to see that.

Except that Intel have been doing this sort of thing for a long time, and have the longest history of open source graphics drivers of any vendor. They've not been ignoring anything. Instead, this is perhaps better seen as maturity of Vulkan drivers; the basics are there, and they're moving onto corner cases and optimisation.

DXVK in this case is "simply" giving the driver developers a much greater data set to test against. Same thing happened when VP and Feral started to use GL4.x features actually. I say simply in quotes, btw, because DXVK is a great piece of work that is definitely helping driver developers, and there's nothing simple about that: quite the opposite, it's hard, and that's why it's exposing problems!
danniello 19 September 2018 at 3:08 pm UTC
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 19 September 2018 at 3:10 pm UTC
mirvThey'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.
mirv 19 September 2018 at 5:19 pm UTC
View PC info
  • Supporter
dannielloSorry 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)...

Hardware got complicated is the short version. So "workarounds" are something touched on in Ekstrand's blog. In this case it's DXVK doing something less than optimal (and there are indeed reasons for it), but then the backend compiler can notice this case and optimise it. Is it the responsibility of one or the other? Yes, no, both. The more ways of doing things the drivers are exposed to, the more they can stabilise, and the more code pathways can be optimised, and so on.

Consoles have similar issues, but the hardware is well known, and that helps quite a lot. The (game) developer knows exactly what's going on, and any driver type interface is also well tested. There's only one "way" to do things (well, ok, not one, but there are far fewer than compared to a desktop system).

To put into perspective: you have 4 of a certain resource on a console. On a desktop you might have 8 instead, or 24, or 2, or none at all. So it's really hard for a driver to work with all of that, and developers try really hard not to be quite so concerned about it. Vulkan puts some of that driver knowledge into the developer's hands, for the developer to sort out, which makes the driver much easier to write. The developer can basically say "well, that doesn't exist, so I won't even try do things that way, but I know another way to do things". Removes much of the guesswork (and complexity) from the driver.

_but_

There might be something a game is trying to do. The API doesn't allow it, however a particular hardware vendor (nvidia, amd, intel) know that their hardware can actually do it....so they put a workaround in their driver. If that scenario is detected, then actually the developer is trying to do xyz, and the driver can do that a "better" (for some definition of better) way.

So in this case, Ekstrand is saying there are cases of DXVK jumping through 17 hoops to do something, but the backend compiler can optimise to make it only jump through 4 hoops. And actually it's not so much a workaround as it is making the compiler better - they're relatively generic optimisations to the compiler that help a lot more than just DXVK.

I hope that helps explain it a little bit.
Leopard 19 September 2018 at 7:27 pm UTC
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 19 September 2018 at 8:05 pm UTC
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 19 September 2018 at 9:06 pm UTC
RussianNeuroMancer
mirvThey'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 19 September 2018 at 9:09 pm UTC
m2mg2
RussianNeuroMancer
mirvThey'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 19 September 2018 at 9:48 pm UTC
mirvI hope that helps explain it a little bit.
Dunno about anyone else, but it was useful as all get out to me.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Community Livestreams
  • Decisions: „Life Is Strange: Before The Storm“
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts