Mesa 20.2 stable with this new default should debut around the end of August and make it into the autumn Linux distribution releases.
Announcement
Collapse
No announcement yet.
Radeon RADV+ACO Vulkan Performance Is In Great Shape For Mesa 20.2
Collapse
X
-
Originally posted by Azpegath View PostMichael I've been playing a lot of Mad Max with the Vulkan rendered and had huge issues with micro-stuttering, even on my new 3950X with 32 GB of RAM. Still with my R290 though.
The thing is that when I tried the same game with the same settings in Windows, I got a steady 60 fps consistently.
So I was hoping that perhaps ACO will solve those micro-stutters. You would be able to see those on your graph of frame-times, right?
It would be interesting to see you test that, even though you probably wouldn't be testing on a R290. But if you would test on that (perhaps together with a slew of older cards that still support Vulkan and ACO) it would be great! I'd give you a $10 tip, since I'm already a lifetime member
According to the MR description, cache misses have caused stuttering which is greatly smoothed by some extra caching in a hash.
- Likes 4
Comment
-
Originally posted by Azpegath View PostMichael I've been playing a lot of Mad Max with the Vulkan rendered and had huge issues with micro-stuttering, even on my new 3950X with 32 GB of RAM. Still with my R290 though.
The thing is that when I tried the same game with the same settings in Windows, I got a steady 60 fps consistently.
So I was hoping that perhaps ACO will solve those micro-stutters. You would be able to see those on your graph of frame-times, right?
It would be interesting to see you test that, even though you probably wouldn't be testing on a R290. But if you would test on that (perhaps together with a slew of older cards that still support Vulkan and ACO) it would be great! I'd give you a $10 tip, since I'm already a lifetime member
Also, perhaps the issue could be with the number of threads. Some older ports have issues with more than a certain number of cores. Maybe that's it? I don't know, just throwing some ideas here. Sometimes even Vsync could be the culprit. Or even just a bad port.
Comment
-
Originally posted by anth View PostI wonder how these compilers would compare with a slower CPU. The main advantage of ACO is compile time, so we might see a bigger difference in minimum frame rate.
Some vulgarization from specialists would be welcome.
Comment
-
Vega 64 runs amazing with aco ever since it got released. The issues I had with Linux Gaming got purged more and more by the good and eager devs of the community. Regarding issues with mesa-aco I can report none for half a year now.
Btw, Apex Legends runs with 144 fps on 1080p and very high settings
Originally posted by Mez' View PostAs an absolute non geek, I'm also wondering how a compiler can affect the performance of the end result driver. My initial non geek thought would be that it's just a matter of time of compilation, not performance.
Some vulgarization from specialists would be welcome.Last edited by ntropy; 14 July 2020, 04:19 AM.
- Likes 2
Comment
-
Of course it could be related to power settings on the card or something.
Comment
-
Originally posted by ntropy View PostIf you render a frame with the GPU, the frame will go through a pipeline of elements in which the final picture gets composed. The most basic pipeline has a set of vertices at the beginning, so a set of coordinates and then it goes into a vertex shader, a tesselation shader, a fragment shader and much more. This is the so called render pipeline. All these shaders get compiled real-time and it depends on the game how its done. Some games pre-compile a lot of shaders on first load, others are more gpu-intensive and calculate everything anew with real lightning and so on. These little shader compilation, need a compiler and llvm wasnt made for this originally. So with aco there was a big boost
But if it compiles complex stuff in real-time during the games (I thought it was the radeon driver package compilation ), I understand why the use of one or the other can lead to differences in performance. Your explanation served its purpose. Thanks for taking the time.
- Likes 2
Comment
-
Originally posted by zboszor View Post
I think you might be interested in this patch: https://gitlab.freedesktop.org/mesa/..._requests/5865
According to the MR description, cache misses have caused stuttering which is greatly smoothed by some extra caching in a hash.
- Likes 4
Comment
-
Originally posted by Mez' View PostIt's still quite abstract to me...
But if it compiles complex stuff in real-time during the games (I thought it was the radeon driver package compilation ), I understand why the use of one or the other can lead to differences in performance. Your explanation served its purpose. Thanks for taking the time.
Before he shows the rendering pipeline from vertex to fragment shader, he explains the command buffer, so dont get confused there in the beginning.
I have a very basic OpenGL Project here: https://github.com/ntropy83/pandora
If you go to the folder bin/shaders you will find the programm code for the fragment and vertex shader. In my program there are only 2 of those programming snippets, in AAA games you have several thousand. Those little programm snippets are used to calculate the vertices or the mesh of an object then in game and need to be compiled.
Sometimes you see that steam downloads in Linux, Vulkan shader definitions for a game. Those are precompiled shaders, it downloads to minimize stuttering for you in game.
The process is the same in windows, but you have much more precompiled shaders there and often games already ship them. So the stuttering is never an issue there. It will be gone for Linux too eventually, with more people playing and compiling shaders. Some stuttering tho will persist with heavy graphics intense titles, but that is for windows too. And if your GPU is fast enough, you wont even notice.Last edited by ntropy; 14 July 2020, 07:13 AM.
Comment
Comment