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
- Kerbal Space Program spiritual successor Kitten Space Agency now has a Linux version
- NVIDIA hiring Linux driver engineers to help with Vulkan, Proton and more
- Happy four years to the Steam Deck - still the top PC gaming handheld
- Discord delay global rollout of age verification to improve transparency and add more options
- Steam Next Fest - February 2026 is live with tons of demos
- > See more over 30 days here
- steam overlay performance monitor - issues
- Xpander - Nacon under financial troubles... no new WRC game (?)
- Xpander - Establishing root of ownership for Steam account
- Nonjuffo - Total Noob general questions about gaming and squeezing every oun…
- GustyGhost - Looking for Linux MMORPG sandbox players (Open Source–friendly …
- Jarmer - 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.
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
^_^
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
^_^
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. :-)
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. :-)
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
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
When I'll have time, I'll try to narrow down the change in Mesa that caused performance regression and flickering.