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!
Reward Tiers:
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!
Login / Register
- NVIDIA announce a native Linux app for GeForce NOW
- KDE Plasma 6.6 will finally stop the system sleeping when gaming with a controller
- NVIDIA announce DLSS 4.5 with Dynamic Multi Frame Generation, plus DLSS Updater gets Linux support
- Mesa RADV driver on Linux looks set for a big ray tracing performance boost
- Linaro reveal they're collaborating with Valve for the Steam Frame
- > See more over 30 days here
- New Desktop Screenshot Thread
- Xpander - Weekend Players' Club 2026-01-09
- on_en_a_gros - Will you buy the new Steam Machine?
- Xpander - Browsers
- Xpander - A succesfull Windows-Ubuntu migration the story
- LoudTechie - See more posts
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck
Modified 0001-wined3d-Do-not-pin-large-buffers.patch to use 0x80000 instead of 0x10000
What does it make exactly? And improves it performance in general e.g. for Vega too?
Thx
Edit: looked into the patch. Its easy to change. I will try it too.
View PC info
And other important thing is nvidia cards depend of higher frecuency and higher ipc cpu aka ryzen is slower (still oc)
i5 8600K at 4.5ghz or more (5.0ghz will be ideal) is highly recommended
^_^
View PC info
View PC info
But in wine cpu frecuency have final word in performance (especially on nvidia gpus), especially coffelake at 4.8ghz or more
Ideal cpu maybe appears when a cpu can give 300 points* in cinebench R15 single thread
*80-90% more single thread performance than ryzen at 4.0ghz
Maybe some day wine left single thread performance dependency
^_^
View PC info
View PC info
For before cited reason intel at more 4.8ghz or more is highly recommended, however before cited cpus is very good but is dont be ideal cpu for wine (single thread performance)
^_^
For my particular setup looks like 0x80000 gave a bit more performance.
Your experience might vary due to different GPU?
So, pure experimentation without knowing what I am doing. :-)
View PC info
If you increase it, it will not pin only even larger buffers. I.e. increasing it means basically further reducing cases when the patch is used.
So I dont know if with padoka mesa 17.3 amdgpu_pm_info is false and the card works like intended or if with oibaf mesa 17.4 the card clocks much more like intended but wine / mesa 17.4 is so inefficent that the higher clock cant translate in higher fps ... very strange
Edit: found this:
https://lists.freedesktop.org/archives/dri-devel/2017-November/157694.html
drm/amdgpu/powerplay/vega10: fix typo in register base index
maybe this fixes in 4.15 (cross my fingers that all changes make it to 4.15) the strange clocking of Vega
https://devtalk.nvidia.com/default/topic/1025576/linux/multihead-rendering-performance-issue-/
Not directly related to problems seen here of course, but my take on the above is that it smells of global locks.
I.e. that is one reason that the four cards (driver) affect each other.
EDIT: just found the global wined3d_mutex_lock/unlock - didn't go looking until now - looks like a good place to start digging deeper. Global shared lock for everything related to wined3d. IMHO Will not scale on multiple threads, especially not on Ryzen's design with CCXs. Might be I totally misunderstand how it is implemented though. :-)
View PC info
Its not so much fun to test with my patchy setup ... 17.3-rc3 gl_thread works, with rc4 no and so on ... the utilization of the card differs so much, the patched 4.14 kernel etcetc
View PC info
View PC info
View PC info
View PC info
40 fps, no flickering
OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0 / 4.13.0-1-amd64, LLVM 5.0.0)OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel (git-43a6e84927)
20-30 fps, flickering
OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0 / 4.13.0-1-amd64, LLVM 5.0.0)OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel (git-386f6cd041)
Must be some kind of regression. I can open a separate bug about it.
I wonder though if newest Mesa needs a newer kernel to work better.
I also noticed that now at least one core is always loaded for me at 100%.
Despite that its amazing to see the progression of wine. Thumbs up and kudos to the developers.
ps: Does the patch work for y with the invisible surfaces? I think that are the two most annoying bugs: invisible hounds and invisible surfaces. Or are there more? With 2.21 I dont get any more freezes. I tried yesterday 2.20 staging and within 5 minutes (near Novigrad) the whole PC freezes
View PC info
When I'll have time, I'll try to narrow down the change in Mesa that caused performance regression and flickering.