Getting closer. :-)

* Built my own from 2.20 sources
* Applied all staging patches
* Modified 0001-wined3d-Do-not-pin-large-buffers.patch to use 0x80000 instead of 0x10000
* Used -O3 and -march=native

EDIT: Results 15-20% fps improvement. :-)

Can y please elaborate? Y applied all staging patches or only the 4 that are important for TW3? And most interested in this:

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.

I don't want to mess with installing custom coolers on a GPU :) CPU with Noctua is more than enough for me for custom installations. Getting something like Sapphire Nitro does the job.

Ok, understand that. My installation gave me some heartstopping moments - I put the card in the case after installation and forget to connect the power cables, turn on and nothing :P

Getting closer. :-)

* Built my own from 2.20 sources
* Applied all staging patches
* Modified 0001-wined3d-Do-not-pin-large-buffers.patch to use 0x80000 instead of 0x10000
* Used -O3 and -march=native

EDIT: Results 15-20% fps improvement. :-)
So 28-32 fps while in the wilds and roughly 22-24 in Novigorad.

Massive improvement to 2.20 vanilla as with build above even fighting is now smoother (at 30fps level but still!).

Most improved in the wilds, not so much in Novigorad.


Still slow when storms and in Novigorad though:

Sorry if I'm spamming to many pictures, just let me know if that is the case. :-)

Good tests however must wait for staging 2.21

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

^_^

And other important thing is nvidia cards depend of higher frecuency and higher ipc cpu aka ryzen is slower

You can use higher frequency RAM for improving that.

And other important thing is nvidia cards depend of higher frecuency and higher ipc cpu aka ryzen is slower

You can use higher frequency RAM for improving that.

Memory improve some, in coffelake is notorious between ddr4 2666mhz and ddr4 3200mhz

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

^_^

And other important thing is nvidia cards depend of higher frecuency and higher ipc cpu aka ryzen is slower

You can use higher frequency RAM for improving that.

Memory improve some, in coffelake is notorious between ddr4 2666mhz and ddr4 3200mhz

I mean IPC / thread performance and for Ryzen, not for Intel. I was commenting on "aka ryzen is slower". Faster RAM makes inter-core bus be faster.

I mean IPC / thread performance and for Ryzen, not for Intel.

I was commenting on "aka ryzen is slower".

Faster RAM makes inter-core bus be faster.

As commented before memories help but in wine dont offer same improve compared cpu frecuency (single thread performance is more important, ryzen lack of good single thread and higher frecuencies)

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)

^_^

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.

Not sure exactly but since it was one of the key patches I tried running with same, smaller and larger.
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. :-)

So, pure experimentation without knowing what I am doing. :-)

It changes the limit at which the buffer is not pinned. As the comment there says:

Some applications map the whole buffer even if they
only update a small portion of it. If we pin such a
buffer into system memory things get very slow as
we upload the whole buffer even though just parts of
it changed. Most drivers can handle this case more
efficient using the OpenGL map functions. Applications
affected by this problem are Banished and Witcher 3.

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.

Just for the notes: tried oibaf ppa again with mesa 17.4 - the Vega clocked like in Windows. No Problem to reach the maximum boost with 1590 sclock / 800 mclock. But it gives me no improve in fps. The opposite is true: slightly less fps with more stutter. And graphical glitches.

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

Looks like wine-staging+nvidia users are not the only ones suffering from weird synchronization/doing-nothing-useful in the nvidia kernel module:
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. :-)

Hi @all. I played on weekend a little more with TW3 on Wine 2.21 with the 4 staging patches, Padoka stable ppa (now 17.3-rc4): I cant use mesa_glthread=true anymore. I get a memory access violation notification in the console or Wine/TW3 launches and the screen stayed black. Without glthred=true I can start TW3. I play now again on 2560x1080 and lowered the settings to high with hairworks off, shadows middle and background population middle. In Oxenfurt on night with rainy weather my fps dropped to around 15(!). In the wilderness I got around 40fps and in villages and cities around 20-25 fps. With this settings not so nice. Playable but hmmm. Funny that the Vega now clocks better and more agressive. Very often it clocks to max boost and reaches the powertarget with around 150 Watt ... very strange what the gpu calculates for so low fps. On Windows I undeclock/undervolt my card to 1542 MHz and the card renders much more fps. Strange ...

Hi @all. I played on weekend a little more with TW3 on Wine 2.21 with the 4 staging patches

Were you able to build 2.21 with those staging patches? They fail to apply for me. Staging should catch and be rebased on 2.21 first.

if I apply the patches to wine tag/wine-2.21 I can apply 3 of them (GenerateMips fails). If I try to apply to the master all patches fails. Hope to get 4.15-rc1 this weekend with official wine-staging 2.21 and roll back to mesa 17.2 to get more stable results.

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

I tweaked staging patches manually to make them applicable to Wine master (more exactly only TW3 related patchsets). xaudio patch isn't needed anymore now. I'm building Wine and will report here how it goes.

Józef also made a patch that fixes invisible surfaces (bug #43131.

Resulting Wine though has significantly worse performance than before now (around 20fps for me). And there is intermittent flickering. Not sure what's going on, I'm now rebuilding it without that surfaces patch to see if it's related.

OK, I narrowed it down to Mesa itself. With older Mesa I get 40 fps again and no flickering:

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%.

Thank y Shmerl, for me with mesa 17.4 I got a lot of flickering while moving and in the cutscenes. with mesa 17.3-rc4 (most recent on padoka stable) I cant use glthread and back on mesa 17.2 (ubuntu 17.10) my performance is not so nice (between low 20 to maybe low 40). Its playable but not so much fun. Hope it will get better with newer versions of kernel/mesa/wine.

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

Freeze was fixed only recently, so it's not in 2.20. The extra patch fixes invisible surfaces around underground areas, but invisible / messed up monsters is a separate issue. I still get the later.

When I'll have time, I'll try to narrow down the change in Mesa that caused performance regression and flickering.