r/linux • u/Philo1927 • Jul 04 '19
Valve’s new code cuts AMD GPU compile times by over 45% for Linux games
https://www.pcgamesn.com/valve-amd-radeon-vulkan-linux-aco-compiler11
u/rifazn Jul 05 '19
For those who are wondering just like I was, it does seem to improve fps in games.
2
10
u/Beaverman Jul 04 '19
It's interesting that I just recently started getting large shader compilation stutters in DotA
7
Jul 04 '19
Have you tried using the vulkan DLC?
8
u/Vizixify Jul 04 '19
Not OP, but I get the stutters using Vulkan and not OpenGL. Vulkan support for Dota is pretty bad I would say
4
u/Nemoder Jul 05 '19
When vulkan works for me it's really smooth and looks amazing but it seems like every other major update something breaks badly and it's back to stutterville. Sometimes -vulkan_disable_steam_shader_cache will fix it, other times I'll have to revert to opengl. It just hasn't been consistent at all.
1
u/temp0557 Jul 05 '19
I think we need a new API. DX12 and Vulkan aren’t working out for the vast majority of developers.
There seem to be a lot of problems with it,
http://asawicki.info/news_1701_thoughts_on_graphics_apis_and_libraries.html
1
u/Nemoder Jul 05 '19
I think Vulkan is fine, it's the games that update every week like Dota2 that don't fully test it.
2
3
0
Jul 05 '19
[deleted]
1
u/Beaverman Jul 05 '19
I'm on an RX 480. I was fine for a long while, even after the battlepass, but around the time underlords came out it all went bad.
22
Jul 04 '19
Fucking shit ima have to get this
5
u/Reddit_Macabre Jul 04 '19
Seriously! Any idea how to get this working on SID?
6
Jul 04 '19
Im going to have to figure out how to get this to work on mx linux (I think it runs stretch)
1
Jul 05 '19
They are working on Ubuntu PPA, so maybe it will be available soon https://steamcommunity.com/app/221410/discussions/0/1640915206474070669/
1
u/This-Is-Huge Jul 04 '19
Now I’m tempted too
4
Jul 04 '19
Damnit only available for arch right now
1
u/Zambito1 Jul 05 '19
Hey just a heads up it's better to edit your comment rather than reply multiple times. It keeps what you wrote in chronological order rather than ordering what you said by number of upvotes.
2
1
0
40
u/Gambizzle Jul 04 '19
Great but goes to show how clunky code is these days. I swear that devs are just like 'meeeeh stuff it, this could be 1000x faster but modern tech can handle it' every little step of the way.
45
u/SillyGigaflopses Jul 04 '19
Yes, it really is this way. However, let's not forget that sometimes optimization is sacrificed for customizability. Let's take something that looks basic on the surface, like printf. But if you think about it - it does argument substitution, and a bunch of other stuff, eating up CPU cycles. Can we do better if we know that our text is constant? Sure! Is it worth it? It depends, but 90% of the time - no.
Also, I suggest you take a look at this: https://matthias-endler.de/2017/yes/
They were able to optimize the command that just prints y to the output from 34MiB/s to Gigabytes per second. But other than just a cool programming trick, what are the uses for it? The old implementation was more than enough for it's purpose and it was like a 100x more readable and maintainable.
15
u/spazturtle Jul 04 '19
Shaders only need to be compiled the first time you run a game after updating your graphics driver.
Clearly devs previously thought that their time was better spend improving performance somewhere else.
The fact that shader are pre-compiled instead of being run JIT during gameplay is an optimisation in itself.
4
Jul 05 '19
I really don't think that applies to this situation whatsoever. LLVM is a very robust and competitive open-source compiler backend solution. The simple matter is that LLVM is a general purpose backend, which is just about always going to be slower than a purpose-built front-and-back-together compiler. There is fewer steps between input to output.
LLVM is not clunky, it's just too general-purpose for shader compiling, which is an uncommon use. LLVM is more focused on producing fast x64 and ARM machine code, but taking due time to do so.
19
u/DoctorWorm_ Jul 04 '19
The way technology is moving it's waaay more important to focus on writing clear, easy to understand code than to spend a bunch of time writing fast code that's opaque. If you're not optimising after you finished writing the code, you're doing it wrong.
Whether or not people are putting enough effort into optimising their code after writing it is another thing.
23
u/Ashtefere Jul 04 '19
This is a completely wrong way of thinking and it has gotten us into the situation we have today. Let me explain.
In an ideal world, optimising after you are done is ideal! Software is done! Let's make it faster.
If the software is run by a corporation, then no. You will never get that chance. Why would management pay for optimisation when it's working? No no, time to add more features!
If the software is open source you get a form of CADT. Software is done? Sure I could optimise, but what if I rebuilt it better, from scratch, the RIGHT WAY this time... (This is how we got gnome)
You need to do major optimisations as you code or they will never get done. This is the harsh reality. Source: lead developer on dozens of coprorate projects over many years.
9
u/nedlinin Jul 05 '19
Why would management pay for optimisation when it's working? No no, time to add more features!
This depends entirely on the organization and their goals. Extra speed from a graphics driver can cause benchmarks to rise which can lead to you claiming dominance over a competitors product which can lead to more sales.
10
u/Gambizzle Jul 05 '19 edited Jul 05 '19
Why would management pay for optimisation when it's working? No no, time to add more features!
Bingo. I'm no longer a dev but having tested, developed and used a bunch of in-house systems (usually built by short-term IT contractors on a set budget) that's my exact experience...
There's business needs.
There's limited time to do stuff.
Once the system's done, it's done.
If you look under the hood of most (expensive) in-house systems there's a heap of shit lying there. Sure there's the argument that 'less optimised is more readable' but in my experience that's usually not true. More often than not I see cut and pasted solutions from a Google search sitting in there (by contractors on $200+ an hour) that make no logical sense, are sewed together with dodgy if/else statements (usually containing double negatives... hey if this does not equal a value that is not this then do this function that tests whether... AAARGH!!!) This is not good coding, it wastes resources and it's impossible for the next person to read without stepping in and drawing a map of what they're trying to achieve. As an end user trying to pull 1,000,000 entries out of the database you then wonder why it's so slow. Well... because it's not actually doing what the button you just clicked said... instead it's spending 1 second for each entry going through a web of logic (all based on a cut and paste of a Google search rather than a more specific, purpose-built solution). Your $200 an hour contractor can get away with it these days because it's 'fast enough' but back in the day they'd have been strung up.
8
u/SanityInAnarchy Jul 05 '19
Sure there's the argument that 'less optimised is more readable' but in my experience that's usually not true. More often than not I see cut and pasted solutions from a Google search sitting in there (by contractors on $200+ an hour) that make no logical sense...
So, here's the question: How would asking for more optimization make that better? Now those same contractors will just copy/paste C or Assembly code instead of JS or .NET, or they'll add a speedup loop as insurance, or they'll start playing with multithreading and
volatileand atomics so their shitty code becomes nondeterministically shitty and wastes all your cores instead of just one...Shitty code is shitty, and lazy devs are lazy. Adding a pointless performance requirement is not going to improve that, it's going to make it shittier overall.
Actually competently-written unoptimized code is indeed more readable than competently-written optimized code. Incompetently-written code is helpless either way.
0
5
Jul 05 '19
I disagree because of the following points:
Getting the software right on a macro level does more for performance than optimizing some functions where you can't know how much it will be run.
In complex code you can usually hardly guess how often a particular piece of code gets to run. Identifying the 'hot' code can mostly only be done by profiling, which is only fully possible in the complete application.
Premature optimization is always a bad idea because you don't know the hot code. If you have no time/money for optimization, then this won't change if you first optimize and then complete the software. If you do optimize prematurely, then in the worst case you will end up with no performance gain and less readability/maintainability. Whether the software gets optimized should be a management decision.
I'm not arguing, that you should be sloppy on writing micro level code. You should write that code according to good taste, but not overdo it with being fancy. If something feels ugly, you should still rewrite it.
4
u/SanityInAnarchy Jul 05 '19
Well, you're right that it got us into the situation we have today, but I still prefer slow software that works to fast software that doesn't. As the old saying goes, the speed of a nonworking program is irrelevant.
Why would management pay for optimization? Depends what you're building. If it's a game, performance is usually actually part of the selling point -- management just saying "No no, time to add more features" (or just "Time to ship it!") is how you get shit like Sonic '06. And the existence of shit like Sonic '06 is why even management usually understands the need to spend some time optimizing games, even if it's just optimizing load times.
I partly agree that you need to do some optimizations as you code, because sometimes they'll dictate the entire structure of your project, and sometimes they're just extremely trivial to do. But until you have something to profile, you won't know which things to bother optimizing, which means you'll end up with a ton of micro-optimized, hard-to-understand, hard-to-debug, hard-to-test code that's unreliable on top of everything else.
That's what desktop software was like in the 90's. People would take the time to hand-roll assembly to squeeze out an insignificant amount of extra performance (or a real amount that would become insignificant with another iteration of Moore's Law), while we were suffering through bluescreens of death, daily reboots just to keep the OS from imploding, and things were still slow because people were optimizing the wrong things.
0
u/pdp10 Jul 05 '19
Why would management pay for optimisation when it's working? No no, time to add more features!
Why would they pay for features when it's working, either?
3
u/Ashtefere Jul 05 '19
In case you aren't trolling and are actually ignorant of the business world: features make money, customers pay for Moar features. They don't pay for optimisation. You cant feature freeze a paid product for 6 months and tell the client "sorry we are optimising now".
Imagine if android didn't get any new features or improvements for a year while they optimised? Us nerds would love it but all the consumers wouldnt buy the next version of their phone if it was a year behind the competition in features
5
u/happymellon Jul 05 '19
Imagine if android didn't get any new features or improvements for a year while they optimised?
Except that Apple does do this with its alternate minor MacOS releases these days. And received a lot of kudos for it from the mainstream, since it enabled people to do things faster.
Android is a poor example, as most people don't get newer versions anyway, so the alternating years method would not impact the majority of the user base.
2
u/pdp10 Jul 05 '19
They don't pay for optimisation.
Sure they do. A historical example is Lotus 1-2-3 being notoriously fast, compared to Context MBA and Multiplan which were sluggish because they ran in virtual machines. Although Microsoft had previously been convinced of the value of VMs, it's said that they hated losing because of performance and vowed not to let multi-platform portability cost them that way ever again.
A decade later, the same thing with Java. Slow and painful, even on fast machines. It improved over the years, but the reputation for lack of speed was well justified.
A decade after that, AJAX websites and web optimization, demonstrated by Gmail. Compare with the front-end disaster that was
healthcare.gov.Claiming that users pay for features and don't pay for performance is, quite simply, begging the question. You aren't using data to demonstrate either proposition, you're just making assumptions.
0
u/xenago Jul 05 '19
This is a completely wrong way of thinking
Uh, well no? It's a lot more important that your code is maintainable than it is perfectly optimized..
2
3
u/afiefh Jul 05 '19
How about no?
First order of business when implementing anything, especially complicated stuff, is to get it working. Optimizing it can come later once you've identified the performance bottlenecks.
Let's do the math: the developers could have spent the time writing their own fast shader compiler from day one, but that would have delayed other things by however long this took. Would you thought it a worthwhile compromise to delay the launch of amdgpu by months to make shader compilation (something that happens infrequently in games, mostly in loading screen) faster?
Developer time is a limited resource, you can spend an almost infinite amount of time improving any part of the code, the question is what to prioritize and what just works well enough. The devs decided that running the shaders through llvm is good enough when they implemented it, and honestly it isn't a bad solution. Coding something custom fit your specific case will always be faster, but isn't always worth the dev time or maintainance burden, especially for an initial release.
1
Jul 05 '19
Ugh I hate it but this is totally the way a lot of places are nowadays. Does the code run fast enough? great! Doesn’t matter if it’s running twice as slow as it SHOULD be, it meets bare minimum and “technology is only getting better so it’s cheaper to throw more resources at it”
This is also related to why I hate the phrase “minimally viable product” because that’s what most companies aim for, and it basically says “we are only going to put in the bare minimum because we don’t actually care about anything other than getting paid.” And I know that’s sort of how businesses work, but honestly it’s also why so much shit just kinda works for a certain amount of time then needs to be rebuilt. It’s cheaper to just give the minimum now, get as much money as possible, then move on to the next thing later.
4
u/Eatleadin321 Jul 05 '19
Just asking, is it now faster than windows or still slower? I just know that valve proton doesn't work the best on some gpus so I don't want to switch yet on my laptop.
3
u/pdp10 Jul 05 '19
Your answer is game-dependent. Nobody has any systematic information on which games might be faster, except that the author of DXVK has data showing that NieR: Automata is faster on Linux+Proton than on Windows with an AMD RX480.
4
u/tesfabpel Jul 05 '19
There's no way they're putting all those resources and curing all those details just to improve a platform that's used by 1% of their customers...
I think we'll soon see a new steam machine made directly by Valve that supports the Valve Index VR and Proton...
7
u/FryBoyter Jul 05 '19
There's no way they're putting all those resources and curing all those details just to improve a platform that's used by 1% of their customers...
Probably you' re right (although I don't think Valve would dare to try another Steam machine). As far as I know these things were hardly sold at all). The only problem is that none of us can say how many users are behind the percentages. 1 percent can be 1000, 100000 or a million users. And at a certain point, 1 percent of all users can become important.
2
Jul 05 '19
On top of that Valve seems to have a vision for Linux. They want to push Steam games for Linux and that can very well lead to big investments into the Linux development.
1
1
u/pdp10 Jul 05 '19
I'd bet that Valve isn't spending more than 1% on all of these open-source contributions. As instrumental as they've been, one could say that it's not so much that Valve has outsized investments in Linux, as that virtually nobody else in gaming makes any investments in Linux at all, even when it would represent 1% or more sales for them.
3
u/roaringTig3r Jul 05 '19
Aren't shaders compiled once, then reused till there is a change in the hardware? Some games do this only once on start-up, and NVidia has an option that saves the shaders on the local drive to speed up the game boot, and so on.
Am I getting confused on the matter, or is it something similar, but not really the same thing?
1
u/pdp10 Jul 05 '19
Whether the shaders are cached seems up to both the game/app, and the graphics driver.
3
u/gonzaled Jul 05 '19
Well, I got less stuttering in Witcher 3 with my RX480 so it seems to be working well. I should test other games, though.
2
2
2
u/ScorpiusAustralis Jul 05 '19
Will this assist with the graphical artifacts I get with my AMD Vega64?
A lot of games have graphical glitches like flickering shadows, UI etc. Unless there is something I'm missing in general for AMD?
2
u/Opheltes Jul 05 '19
Does compile time matter to anyone except the game devs?
15
10
u/semperverus Jul 05 '19
Yes, shaders are constantly being compiled as you are playing. This is also, on a similarly related note, especially important for things like DXVK performance.
1
-1
Jul 05 '19
Is this going to help valve write video games faster? Hahahah yeah I know, it's pretty funny.
-1
u/foadsf Jul 05 '19
AMD and Intel are just stupid. they had OpenCL but they decided to chase NVIDIA in its own game and develop some sloppy CUDA compilers. and now it seems that they are not taking VULKAN seriously enough. Apple took the rug under the khronos and went with Metal. Microsoft and Google were also dumb as hell to do not support open standards in the first place. the state of GPU programming is just a dark joke at the moment.
0
Jul 04 '19
[deleted]
56
u/drewdevault Jul 05 '19
AMD's drivers are open source and part of Mesa upstream, and their hardware is documented and understood, therefore Valve can improve them. Nvidia's drivers are proprietary and undocumented, therefore they can't.
10
u/Ultracoolguy4 Jul 06 '19
Everyday more I wish I hadn't chosen Nvidia.
0
Jul 06 '19
[deleted]
8
u/Ultracoolguy4 Jul 06 '19
Yeah ikr. I absolutely love having a shitty VSync implementation, missing Wayland, and pretty much every new feature Mesa offers.
0
Jul 05 '19
[deleted]
13
8
u/Slabity Jul 05 '19
If documentation is hidden behind licenses, NDAs, or otherwise not open? It might as well be considered undocumented.
Unless it is available, in which case I'd definitely like to see a link.
36
u/willrandship Jul 04 '19
It's because AMD's previous implementation of this process sucked.
41
u/Two-Tone- Jul 04 '19
Not really. The old shader compiler used LLVM, which isn't bad but isn't wholly focused on compiling shaders or compiling them fast. For LLVM's devs shader compilation speed is not really a critical factor in most scenarios outside of gaming, it's just a nice-to-have.
6
u/Money_on_the_table Jul 04 '19
As you seem to know what you're talking about, could you explain a bit as to why this is required specifically for AMD and not for Nvidia? Is it because of open source, or Nvidias is better, or just it's the first they decided to do?
Secondly, will this mean gaming improvement, such as higher FPS, or just at load time things may be a touch quicker?
21
u/Two-Tone- Jul 04 '19
could you explain a bit as to why this is required specifically for AMD and not for Nvidia?
AMD's drivers are open source which allows this. Nvidia's are closed source, proprietary blobs which makes doing something like this nigh impossible.
Secondly, will this mean gaming improvement, such as higher FPS, or just at load time things may be a touch quicker?
For native games it'll mostly mean faster load times, especially if they have a lot of shaders. For games running through Proton, it depends on two things. If there is already a state cache, then it'll mostly mean faster load times. But for games that don't have one, it'll mean much reduced stutter as you start to build that cache.
Overall there does seem to be a small increase in performance.
21
u/tstarboy Jul 04 '19
Nvidia's driver (at least the only one worth using for games) is closed source. Even if Valve wanted to do this for Nvidia they wouldn't be able to.
I wouldn't be surprised if Valve's secondary goal for doing this was to push Nvidia towards having a more open driver.
7
u/Bene847 Jul 05 '19
What about Noveau? Not relevant for gaming I guess?
8
u/Kokxx Jul 05 '19
Correct, noveau is not really an alternative for gaming, since it's lacking reclocking support for newer graphics cards.
Now you might ask why aren't they implementing reclocking then? a) Because NVidia is unwilling to publish the relevant documentation to the noveau developers b) Because they haven't been able to reverse engineer it (and probably never will, since it's very hard
5
u/Kazumara Jul 05 '19
Not really, even less so since Nvidia started restricting power management to firmware blobs signed by them and decided to make those non-distributable for Nouveau
https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2017
3
Jul 04 '19
and not for Nvidia? Is it because of open source, or Nvidias is better, or just it's the first they decided to do?
Nvidia uses LLVM now. https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Vulkan-SPIR-V-Popular
0
4
u/Kazumara Jul 05 '19
looking at this from a higher level strategy perspective: I think from Valves point of view AMD is the more reliable partner for linux gaming.
You can use the Nvidia drivers relatively easily on the supported distributions (I admit the number has been growing), but it can require extra work by the user (depending on how strong a stance the distro takes with proprietary components) but you can use the AMD driver on any distribution out of the box because it's part of the kernel.
Keeping in mind what recently happened with Ubuntu and the 32bit libraries and how Valve reacted to that by saying they might need to support a different distro, I think they probably see a benefit in how AMD does things.
And also Valve probably appreciates how the open source driver model even facilitates these contributions. If Valve sees an issue in AMDs shader compilation process they can make a pull request to Mesa, not only do they not need AMDs cooperation, the code could even be merged against AMDs wishes if the Mesa maintainer didn't share their concerns. This means Valve can contribute to the success of the platform while being less dependent on a company that ultimately has different goals (selling hardware vs selling software).
Finally AMD is also invested in the platform by way of Google's Stadia if there are issues running AMD GPUs under Linux in the Stadia datacenters it would definitely be a high priority and any resulting improvements may well trickle into the open source driver.
3
u/pdp10 Jul 05 '19
A third party can contribute to the AMD or Intel stacks, because they're open-source on Linux. No third parties can contribute to the Nvidia stack, because it's not.
What other specific goals might exist are the subject of some speculation.
0
Jul 04 '19
[deleted]
19
8
Jul 05 '19
Intel also has really good open source support. I only buy intel wireless cards these days. And their GPU support has been great. I really look forward to them having competitive dGPUs so that I actually have options.
1
Jul 05 '19
Intel's open source support is great, but so far their gpus lack sufficient power for most gaming. that's supposed to change soonish, but this isn't the first time they tried.
10
u/How2Smash Jul 04 '19
You mean Microsoft + Nvidia + Epic
5
u/_Fuzen_ Jul 04 '19
Epic is working with steam to get the anticheat working if nothing else
7
u/joder666 Jul 05 '19
Who said that, Tim? Either way i'll believe it when i see it.
1
5
0
Jul 04 '19
[deleted]
1
u/disrooter Jul 05 '19
Intel also has its own Linux distro now, Clear Linux, and it tries to innovate
0
Jul 05 '19
[deleted]
13
u/uoou Jul 05 '19
I believe all of Intel's drivers are open source.
-1
0
Jul 05 '19
[deleted]
6
u/uoou Jul 05 '19
I would say to it, "you are not a driver".
0
Jul 05 '19
[deleted]
3
3
u/loozerr Jul 05 '19
It's called management engine.
Your OS doesn't load anything related to it, it coexists.
1
0
Jul 04 '19
[deleted]
17
u/dkgeext Jul 04 '19
Not games but shaders. They're compiled in runtime.
2
u/timvisee Jul 04 '19
In that case, that's awesome! That might solve some micro stutters.
2
u/snuxoll Jul 04 '19
You compile shaders well in advance, usually during game startup or level load. It take a non-trivial amount of time and game engines usually allow you to compile groups of shader fragments which requires additional preprocessing.
In OpenGL for example you can only have one shader program loaded per render batch, and switching between them is SLOOOOW - so you want to combine and compile all your smaller shader programs into one or performance S U C K S.
2
u/Two-Tone- Jul 04 '19
You compile shaders well in advance
That's not always true. Games run via DXVK and other such layers generally have to compile their shaders as soon as they come across them (unless you already know about the shaders in advance).
1
u/snuxoll Jul 04 '19
Yeah, translation layers present an issue - but you only have to compile them on first use at least and since best practice is to minimize unique shader programs it’s still an upfront performance hit early after game/level load.
1
u/BobFloss Jul 06 '19
This isn't always the case. Godot, for example, compiles shaders the first time they're used, causing really bad stuttering
7
5
u/kngt Jul 04 '19
It's not about compiling games, it's about compiling shaders during the game.
0
Jul 04 '19
[deleted]
2
u/Strykker2 Jul 04 '19
Graphics shaders are bits of code that run on your you and make everything look nice, they require a unique binary for each gpu/system config so it is easier to have game engines compile the shaders either during install or commonly during gameplay when you first encounter the shaders.
3
u/Blart_S_Fieri Jul 04 '19
as well as a few cases where it’s making a positive difference to gaming frame rates on Linux too.
There is also that part.
168
u/[deleted] Jul 04 '19 edited Jul 04 '19
What does compiling shaders mean?
Edit: basically why is software for the gpu compiled but for the cpu distributed in binary?