https://bugs.winehq.org/show_bug.cgi?id=42592
Bug ID: 42592 Summary: The Witcher 3 has poor performance Product: Wine Version: 2.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: shtetldik@gmail.com Distribution: ---
Created attachment 57528 --> https://bugs.winehq.org/attachment.cgi?id=57528 The Witcher 3 with GALLIUM_HUD, CSMT on.
I tested latest TW3 in Wine 2.3 with staging patches applied (built from source).
See the attached screenshot for results with low graphics settings.
Hardware: CPU: Intel Core i7 4770. RAM: 16GB. GPU: AMD RX480 (4GB VRAM), Mesa 17.1.0-devel (git-4dc42ae792). Resolution: 1920x1200.
Resulting is pretty bad (6fps inside the game). Not sure if it's specific to Mesa or not. Anyone with Nvidia blob, feel free to post your benchmarks to compare. If it's Mesa specific, I can open a Mesa bug too.
https://bugs.winehq.org/show_bug.cgi?id=42592
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com
--- Comment #1 from Józef Kucia joseph.kucia@gmail.com --- Created attachment 57530 --> https://bugs.winehq.org/attachment.cgi?id=57530 Buffer pool hack
Could you please test if the attached hack helps?
https://bugs.winehq.org/show_bug.cgi?id=42592
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
https://bugs.winehq.org/show_bug.cgi?id=42592
Anthony Jagers noonetinone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noonetinone@gmail.com
--- Comment #2 from Anthony Jagers noonetinone@gmail.com --- Is there a demo? I don't own the game.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #3 from Shmerl shtetldik@gmail.com --- (In reply to Anthony Jagers from comment #2)
Is there a demo? I don't own the game.
No, there is no demo unfortunately.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #4 from Shmerl shtetldik@gmail.com --- (In reply to Józef Kucia from comment #1)
Created attachment 57530 [details] Buffer pool hack
Could you please test if the attached hack helps?
I just tested your hack, and it helps a huge deal. I'll attach screenshots with benchmarks.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #5 from Shmerl shtetldik@gmail.com --- Created attachment 57534 --> https://bugs.winehq.org/attachment.cgi?id=57534 The Witcher 3, low settings, CSMT on, buffer pool hack
Buffer pool patch applied. Low graphics settings, same hardware as above. Framerate: 60fps. CPU usage is also higher than without the buffer pool patch.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #6 from Shmerl shtetldik@gmail.com --- Created attachment 57535 --> https://bugs.winehq.org/attachment.cgi?id=57535 The Witcher 3, high/ultra settings, no hairworks, CSMT on, buffer pool hack
Buffer pool patch applied. High/ultra graphics settings, hairworkds off. Same hardware as above. Framerate: ~45fps.
That's where GPU starts being loaded almost at 100%, so higher end card than my current AMD RX480 can probably help here. Without pool hack GPU isn't fully loaded even on max settings.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #7 from Shmerl shtetldik@gmail.com --- Created attachment 57536 --> https://bugs.winehq.org/attachment.cgi?id=57536 The Witcher 3, high/ultra settings, no hairworks, no SSAO, CSMT on, buffer pool hack
Buffer pool patch applied. High/ultra graphics settings, ambient occlusion (SSAO) switched off, hairworkds off. Same hardware as above. Framerate: ~50fps.
That yellowish mesh on the max settings is caused by ambient occlusion (SSAO) setting. When it's off, it doesn't appear.
https://bugs.winehq.org/show_bug.cgi?id=42592
Simon Bolokanov sbolokanov@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sbolokanov@abv.bg
https://bugs.winehq.org/show_bug.cgi?id=42592
tt_1 herrtimson@yahoo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herrtimson@yahoo.de
https://bugs.winehq.org/show_bug.cgi?id=42592
graham@heunox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |graham@heunox.com
https://bugs.winehq.org/show_bug.cgi?id=42592
Fincer fincer89@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=42592
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=42592
Ivan Set s.i.v.892@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s.i.v.892@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
Sami Kankaristo sami@kankaristo.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sami@kankaristo.fi
https://bugs.winehq.org/show_bug.cgi?id=42592
scix asheldon55@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asheldon55@gmail.com
--- Comment #8 from scix asheldon55@gmail.com --- Performance is still quite bad with my Nvidia system (20 - 35 FPS average), and is mainly not affected by graphical settings.
Hardware info: CPU: Ryzen 1600 @ 3.6 ghz RAM: 16 GB GPU: 980 TI with 384.47 binary drivers Wine version: 2.11-staging Resolution: 2560x1440 (but still equally slow at lower resolutions)
https://bugs.winehq.org/show_bug.cgi?id=42592
gasinvein@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gasinvein@gmail.com
--- Comment #9 from gasinvein@gmail.com --- I have exactly same as above results. About 25 fps, not noticeably changing neither with any graphical settings from low to ultra, nor with different resolutions. i7 2600, GTX 1060, drivers 375.66, wine 2.11-staging
https://bugs.winehq.org/show_bug.cgi?id=42592
Krešo Kunjas deresh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deresh@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #10 from Krešo Kunjas deresh@gmail.com --- @phillip (In reply to scix from comment #8)
Performance is still quite bad with my Nvidia system (20 - 35 FPS average), and is mainly not affected by graphical settings.
Hardware info: CPU: Ryzen 1600 @ 3.6 ghz RAM: 16 GB GPU: 980 TI with 384.47 binary drivers Wine version: 2.11-staging Resolution: 2560x1440 (but still equally slow at lower resolutions)
is this with patch applied?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #11 from scix asheldon55@gmail.com --- (In reply to Krešo Kunjas from comment #10)
@phillip (In reply to scix from comment #8)
Performance is still quite bad with my Nvidia system (20 - 35 FPS average), and is mainly not affected by graphical settings.
Hardware info: CPU: Ryzen 1600 @ 3.6 ghz RAM: 16 GB GPU: 980 TI with 384.47 binary drivers Wine version: 2.11-staging Resolution: 2560x1440 (but still equally slow at lower resolutions)
is this with patch applied?
I believe staging already includes an updated patch going by this comment in the source code:
/* 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. */
So yes, performance is still affected with this patch.
https://bugs.winehq.org/show_bug.cgi?id=42592
KiaraNyasha mihaahr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mihaahr@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #12 from Krešo Kunjas deresh@gmail.com --- For latest staging i get around 25fps, but that is still unplayable...
Nvidia 1070 with nvidia blob 384.59
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #13 from Shmerl shtetldik@gmail.com --- (In reply to Krešo Kunjas from comment #12)
For latest staging i get around 25fps, but that is still unplayable...
Nvidia 1070 with nvidia blob 384.59
Currently Nvidia blob somehow suffers a major performance degradation in comparison with Mesa / radeonsi.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #14 from Krešo Kunjas deresh@gmail.com --- (In reply to Shmerl from comment #13)
(In reply to Krešo Kunjas from comment #12)
For latest staging i get around 25fps, but that is still unplayable...
Nvidia 1070 with nvidia blob 384.59
Currently Nvidia blob somehow suffers a major performance degradation in comparison with Mesa / radeonsi.
Do you know if it plays better with some older stable releases?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #15 from Shmerl shtetldik@gmail.com --- (In reply to Krešo Kunjas from comment #14)
Do you know if it plays better with some older stable releases?
No, as far as I remember, it was always worse with Nvidia blob.
https://bugs.winehq.org/show_bug.cgi?id=42592
Daniel Oom oom.daniel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oom.daniel@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
amazzy mazzarito@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mazzarito@gmail.com
--- Comment #16 from amazzy mazzarito@gmail.com --- https://dev.wine-staging.com/patches/submission/220
This patch implements GenerateMips and helps with performance A LOT...
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #17 from Shmerl shtetldik@gmail.com --- (In reply to amazzy from comment #16)
https://dev.wine-staging.com/patches/submission/220
This patch implements GenerateMips and helps with performance A LOT...
Does it help Mesa too? I'll give a try a bit later.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #18 from Shmerl shtetldik@gmail.com --- (In reply to amazzy from comment #16)
https://dev.wine-staging.com/patches/submission/220
This patch implements GenerateMips and helps with performance A LOT...
It's already in staging: https://github.com/wine-compholio/wine-staging/tree/master/patches/wined3d-G...
I updated the howto and tested it with Mesa. Not much of a difference really, it already loads GPU to 100%. I suppose it's more helpful to the Nvidia blob, which had a specific bottleneck.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #19 from Filippe LeMarchand gasinvein@gmail.com --- (In reply to amazzy from comment #16)
https://dev.wine-staging.com/patches/submission/220
This patch implements GenerateMips and helps with performance A LOT...
For me it doesn't help much, GPU utilization is still about 50% (Nvidia 1060).
https://bugs.winehq.org/show_bug.cgi?id=42592
Kai Krakow kai@kaishome.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@kaishome.de
--- Comment #20 from Kai Krakow kai@kaishome.de --- I can confirm this... Running nvidia-smi and htop in parallel on a second monitor, I can see the GPU hovering around at about 45-65% while some CPU cores are loaded at 80-90%. I guess this may have something to do with how Wine currently implements CUDA and PhysX.
When I use Aard to trigger physical object movement, the game really slows down (it doesn't look like dropping FPS, it looks like everything goes slow motion until objects stop moving around).
Using GTX 1050 4GB with i7-3770K @4.2GHz turbo.
However, within Novigrad, I was able (until some patch or configuration change) to trigger the game into using 100% GPU all the time, with FPS going down to 1 FPS or below. This is triggered in some areas around Triss' house, and also often while talking to people. The game has to be completely restarted to get rid of this slowness. I think this happened when playing around with the STAGING_RT_PRIORITY_BASE setting. Using STAGING_RT_PRIORITY_SERVER now, and it hasn't happened again. The game seems a little bit overall smoother now but still low FPS at only 45-65% GPU load.
Using wine-staging 2.17. Different graphics settings seem to only have a minimal impact on FPS and GPU load, except for during rain and except for some lighting effects which makes FPS really go down and making the game run more slow-motion like. In the latter situations graphics settings seem to have a noticeable (but still small) impact.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #21 from Filippe LeMarchand gasinvein@gmail.com --- I guess this bug should be renamed to something like "Nvidia GPU not fully utilized".
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #22 from tt_1 herrtimson@yahoo.de --- I thought this is a problem with all cards and driver combinations - is there a better performance with AMD cards?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #23 from Shmerl shtetldik@gmail.com --- (In reply to tt_1 from comment #22)
I thought this is a problem with all cards and driver combinations - is there a better performance with AMD cards?
AMD cards are utilized to 100%, so it looks like Nvidia specific issue.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #24 from Shmerl shtetldik@gmail.com --- Created attachment 59484 --> https://bugs.winehq.org/attachment.cgi?id=59484 Performance with Mesa / radeonsi in Wine 2.18 (with needed patches applied)
Max settings, hairwokrds off. Resolution: 1920 x 1200. Average framerate: 40 fps. GPU: AMD Sapphire Nitro+ RX 480. 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-e5e93c727f)
As you can see, GPU is fully utilized.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #25 from mirh mirh@protonmail.ch --- GPU being under or over utilized should not be the point of the issue. Rather, it's the comparisons with the same situations under Windows that bother us. (assuming the bottleneck is not a driver inefficiency)
40 fps on max settings on a RX480 seems really, really good to be honest. Maybe it's a 10-20% below native, but it would be enough to call this a day imo - whenever those patches land.
I'd also leave any CUDA/physx discussion for another thread (if whatever ever confirmed) since it's totally optional stuff, and it's already a PITA to discuss on Windows.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #26 from Shmerl shtetldik@gmail.com --- (In reply to mirh from comment #25)
GPU being under or over utilized should not be the point of the issue.
It's related. Underutilized GPU naturally leads to worsened performance.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #27 from Kai Krakow kai@kaishome.de --- Well, when disabling clothing effect by removing APEX_ClothingGPU_x64.dll the game still doesn't run any smoother. But CPU usage seems to be lower, while the GPU keeps hovering around 45-65%. But cut scenes look overall smoother (so I'm not sure).
Since I guess that the clothing effects are one of the major CUDA users, I guess this is mostly unrelated to CUDA.
When neither CPU nor GPU are maxed out while the FPS are pretty low, there seems to be a problem with synchronization of threads. Something is waiting and it is not a busy loop (otherwise CPU would be maxed out, at least one core). So I'm fine with not discussing CUDA issues here. But if there's another place with CUDA related discussion for the game, I'd be interested in a link.
BTW: There are discussions of whether removing APEX_ClothingGPU_x64.dll has any effect at all, it may be a placebo effect. For me, it seems to change some behavior but overall performance isn't affected. Some people argue that deleting the DLL and the game can still run only means that it wasn't used at all. But I guess this DLL is one optional dependency and the game just falls back to not using GPU-CUDA for clothing at all then (which it seems to use only occasionally anyways), like it is a plugin that will be loaded if it is there.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #28 from Kai Krakow kai@kaishome.de --- I applied the following staging patch: https://dev.wine-staging.com/patches/204/ (shader parameter caching)
This only slightly improves FPS. But it still has a big impact on gameplay:
GPU usage now is 10-20% higher and CPU usage is around 10% lower. Especially during rain, the game runs much better now. The biggest effect it has, tho, is that input lag is reduced by a huge factor even in demanding areas like Novigrad. But Novigrad still runs in slow-motion at times even while CPU usage is lower and GPU usage is a little higher than before. Take note that especially Novigrad doesn't gain that much GPU usage with this patch as I see in other areas of the game.
It is still needed to limit the game to 30 FPS max as otherwise input lag comes back again and the game feels like it's stuttering.
https://bugs.winehq.org/show_bug.cgi?id=42592
Savvy Raghuvanshi sraghuvanshi@college.harvard.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sraghuvanshi@college.harvar | |d.edu
--- Comment #29 from Savvy Raghuvanshi sraghuvanshi@college.harvard.edu --- I have been trying to debug Witcher 3 performance by running the game on Windows using wined3d, as suggested in the WineHQ wiki. However, the game refuses to "accept" the wined3d dll files. If I use the 32-bit 2.19-staging wined3d dlls by placing them in the same directory as the exe file, Process Monitor shows Witcher 3 as opening the dlls, immediately closing them, and opening the Windows System32 versions instead. If I use the 64-bit ones, then the game complains that "GPU does not meet minimal requirements. Support for DirectX 11 is required." Is there a way to force the game to use the wined3d dll files I provide?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #30 from Savvy Raghuvanshi sraghuvanshi@college.harvard.edu --- After messing around for a couple hours (and borking then un-borking my Windows 10 partition) I figured out how to get Witcher 3 to use the wined3d dll files: Unpack the x64 version of the dlls into the bin/x64 folder, and set witcher3.exe to run in Windows 7 compatibility mode. I was able to confirm using Process Monitor that the native version of the dlls are never called.
This gave me much worse performance than even in Wine-staging 2.19 on Arch Linux. In Windows, on my y700 laptop with a 4GB GTX 960m, the GPU was 60-80% usage and CPU was about 22-25% usage. However, I was only getting ~3-6 FPS in the game, and there were texture issues (like Geralt's hair being completely black, or missing).
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #31 from Shmerl shtetldik@gmail.com --- (In reply to Savvy Raghuvanshi from comment #29)
I have been trying to debug Witcher 3 performance by running the game on Windows using wined3d, as suggested in the WineHQ wiki
Why can't you profile it on Linux itself?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #32 from Kai Krakow kai@kaishome.de --- Meanwhile, I upgraded to Wine Staging 2.18 (as provided by Gentoo) with integrated patches supplied via portage patching feature for:
* https://dev.wine-staging.com/patches/205/ * https://dev.wine-staging.com/patches/204/
Overall, the game runs a little bit better now. Numbers stay roughly the same but everything looks smoother overall even when I put back 60fps limit and increase graphic detail.
But one thing I'm seeing now (compared to 2.17 before): The game freezes for short times especially in the beginning and when entering new areas or the map. I believe that's mostly due to the shader caching patch tho I didn't see this effect with 2.17.
I was using both patches already in 2.17. From the news page I don't see any important update that's related to d3d performance. I wonder what makes the difference?
There's one thing I changed at around the same time: I turned off madvise'd huge pages support in the kernel. But that's counter-intuitive.
I currently arrived in Ard Skellig. At the current stage of performance I can clearly see, while walking through the forests, that one graphical bug seems to have some bigger impact on performance:
https://bugs.winehq.org/show_bug.cgi?id=43828
These distortions sometimes reach through the whole forest or are visible as flickering in the background behind the trees while monsters affected by this bug are around. The game runs much more sluggish during that bug, even if such monsters are not in the viewport (like behind me). The flickering effect I see clearly tells me that the visual bug is still rendered even when the affected object itself should not be visible.
I guess that the following bugs could have a similar performance effect:
* https://bugs.winehq.org/show_bug.cgi?id=43158 (medium impact) * https://bugs.winehq.org/show_bug.cgi?id=43131 (small impact)
Since Novigrad is full of these visual bugs, it would explain why it ran so slow. Also, Ard Skellig is full of those bugs in and around villages. I'm seeing performance clearly drop in those areas.
So maybe the above bugs should be cleared first before investigating this further.
When staying away from such visual bugs, the game seems to run really smooth now, even during fights with a few characters around.
https://bugs.winehq.org/show_bug.cgi?id=42592
Christian christian.frank@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christian.frank@gmx.de
--- Comment #33 from Christian christian.frank@gmx.de --- Hi,
sadly i don't own the Witcher 3, but i have very similar performance issues in all DX11 games in wine (Crysis2, Crysis3, Prey 2017 demo)
GPU: NVidia GTX970 (384.90 driver) CPU: Core i5 3570K RAM: 16GB
The CPU load is very high, but:
In all the games the GPU load is roughly only 30-40% and the game fps are bad, also mostly between 30-40 fps or lower. Enabling or disabling graphical settings doesn't make that much difference when it comes to fps or gpu load.
Enabling d3d_perf debug option shows issues with buffer uploads/transfer to mem etc.
There seems to be an big issue with nvidia cards and dx11 in wine :(.
Im sure the perf would be really good if the gpu would be fully loaded.
I think i will open another bug for that issues, cause imho it affects different dx11 games on nvidia in the same way.
Cu, Christian
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #34 from graham@heunox.com --- Something I would like to note. In my experience the 384.x nvidia driver brings with it a significant performance drop and graphical glitches in the witcher3 (under wine) as well. I ended up reverting to 375.66.
This does include the 384.90 nvidia driver, which I tested last weekend.
If I knew how to get fps numbers I would for comparison between the different drivers.
CPU: i7-6700K CPU @ 4.00GHz GPU: GeForce GTX 1080 Ti RAM: 32GB
I am wondering if this is also related to the performance hits being seen on the nvidia cards vs AMD. I'd be curious if you reverted your driver if you still saw the same performance hits with DirectX 11 games.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #35 from Christian christian.frank@gmx.de --- (In reply to Graham from comment #34)
Something I would like to note. In my experience the 384.x nvidia driver brings with it a significant performance drop and graphical glitches in the witcher3 (under wine) as well. I ended up reverting to 375.66.
This does include the 384.90 nvidia driver, which I tested last weekend.
If I knew how to get fps numbers I would for comparison between the different drivers.
CPU: i7-6700K CPU @ 4.00GHz GPU: GeForce GTX 1080 Ti RAM: 32GB
I am wondering if this is also related to the performance hits being seen on the nvidia cards vs AMD. I'd be curious if you reverted your driver if you still saw the same performance hits with DirectX 11 games.
Hi,
you can take a look at the fps in the terminal:
export WINEDEBUG=-all,+fps
before starting the game with wine game.exe
I sadly can't downgrade the driver easily here.
Cu
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #36 from Shmerl shtetldik@gmail.com --- (In reply to Christian from comment #33)
Enabling d3d_perf debug option shows issues with buffer uploads/transfer to mem etc.
Sounds like a driver bug to me. That's the benefit of using Mesa - you can actually check what's going on. With Nvidia blob - tough luck.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #37 from Christian christian.frank@gmx.de --- (In reply to Shmerl from comment #36)
(In reply to Christian from comment #33)
Enabling d3d_perf debug option shows issues with buffer uploads/transfer to mem etc.
Sounds like a driver bug to me. That's the benefit of using Mesa - you can actually check what's going on. With Nvidia blob - tough luck.
Hi,
i am no dev and therefore not sure if it is actually a driver bug or that the wine dx11->opengl translation is ways to inefficient to keep the gpu busy.
I even tried wine dev instead of wine staging today and the fps are even worse, i guess cause more dx11 bits are missing.
Anyway, as nvidia gpus are used by the main wine userbase afaik, wine needs to find a way (together with nvidia i guess) to make the performance of dx11 games actually usable (doesn't help to have a good looking dx11 slideshow) .
Nonetheless, my next gpu will be a amd one anyway due to the nowadays very good and steadily evolving open source drivers and great developer feedback.
Christian
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #38 from Henri Verbeet hverbeet@gmail.com --- (In reply to Christian from comment #37)
Anyway, as nvidia gpus are used by the main wine userbase afaik,
For what it's worth, that's a bit of a misunderstanding. As a rough estimate I'd say about 40-50% of our users are using NVIDIA GPUs, of which about 80-90% are using the proprietary drivers. That's certainly a significant number of people, which of course we'll try to help where reasonably possible. But it's not just about numbers; Wine is in the first place a Free Software project, and quite frankly plenty of us would be happier if more of our users used Free Software drivers.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #39 from Christian christian.frank@gmx.de --- (In reply to Henri Verbeet from comment #38)
(In reply to Christian from comment #37)
Anyway, as nvidia gpus are used by the main wine userbase afaik,
For what it's worth, that's a bit of a misunderstanding. As a rough estimate I'd say about 40-50% of our users are using NVIDIA GPUs, of which about 80-90% are using the proprietary drivers. That's certainly a significant number of people, which of course we'll try to help where reasonably possible. But it's not just about numbers; Wine is in the first place a Free Software project, and quite frankly plenty of us would be happier if more of our users used Free Software drivers.
Thanks for the info ! As mentioned i am also already looking forward to get an amd card :) . Btw, should i open one bug per game for the bad performance or one for all of the games i can test ?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #40 from Kai Krakow kai@kaishome.de --- Upon the pointer to downgrade the nvidia driver, I downgraded back from latest beta to latest stable (still above 375, tho). It may have changed a few bits of how the game feels, nothing dramatic.
But after playing around a little bit, I'm pretty sure that there is no overloading at any point. The game engine just becomes slow: Physics play slow motion, movement is slow motion. If the FPS go down, in-game speed also goes down, like there are some timer ticks missed which the game doesn't pick up within Wine. It almost always looks like the game does not or cannot skip frames to keep up with realtime but just slows down the whole game engine, trying to render every frame...
Something similar is also visible with some "native" ports like Mad Max, and I guess it uses some stuff that Wine also does (wrappers around syscalls etc). The guys from Feral pointed out that this may be a kernel issue, timing handled differently between kernel versions. They suggested to set the CPU governor from default ondemand to performance. Well, that didn't help at all. But at least they could reproduce it later and wanted to get a fix in when a newer kernel version goes stable on Ubuntu (which is their supported platform).
So, with this background: Are there known kernel options which could influence or explain such behavior within Wine? Since I'm on Gentoo and as such using a custom kernel build, I'd happily try a few options.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #41 from Shmerl shtetldik@gmail.com --- (In reply to Kai Krakow from comment #40)
So, with this background: Are there known kernel options which could influence or explain such behavior within Wine? Since I'm on Gentoo and as such using a custom kernel build, I'd happily try a few options.
It's likely the behavior in the Nvidia kernel module, not in Wine.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #42 from Shmerl shtetldik@gmail.com --- I wonder if bad performance with Nvidia is related to the fact that Wine uses Nvidia blob in compat profile. If you run it with forced core profile (which has some other bugs now), does framerate improve?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #43 from Kai Krakow kai@kaishome.de --- (In reply to Shmerl from comment #42)
I wonder if bad performance with Nvidia is related to the fact that Wine uses Nvidia blob in compat profile. If you run it with forced core profile (which has some other bugs now), does framerate improve?
Interesting idea... How do you do that? I'd eagerly try.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #44 from Shmerl shtetldik@gmail.com --- (In reply to Kai Krakow from comment #43)
(In reply to Shmerl from comment #42)
I wonder if bad performance with Nvidia is related to the fact that Wine uses Nvidia blob in compat profile. If you run it with forced core profile (which has some other bugs now), does framerate improve?
Interesting idea... How do you do that? I'd eagerly try.
REGEDIT4 [HKEY_CURRENT_USER\Software\Wine\Direct3D] "DirectDrawRenderer"="opengl" "UseGLSL"="enabled" "MaxVersionGL"=dword:00040005
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #45 from Kai Krakow kai@kaishome.de --- (In reply to Shmerl from comment #44)
(In reply to Kai Krakow from comment #43)
(In reply to Shmerl from comment #42)
I wonder if bad performance with Nvidia is related to the fact that Wine uses Nvidia blob in compat profile. If you run it with forced core profile (which has some other bugs now), does framerate improve?
Interesting idea... How do you do that? I'd eagerly try.
REGEDIT4 [HKEY_CURRENT_USER\Software\Wine\Direct3D] "DirectDrawRenderer"="opengl" "UseGLSL"="enabled" "MaxVersionGL"=dword:00040005
Well, that brings back a lot of visual glitches, like too dark ground textures.
Interestingly the game feels smoother during the first few minutes, and also nvidia-smi shows higher power usage. But the game quickly falls back to the same slow performance as without this registry patch.
Also, walking the same scenes back and forth during testing, I can see that performance starts to drop mostly in areas with lots of visual glitches, and it doesn't return when leaving those areas and going back to the high performing areas.
What's also interesting: With this registry patch, the game doesn't freeze after shutdown, it closes without problems. Previously, the witcher3.exe would stay around hogging many gigs of RAM and no CPU usage, and I had to kill it every time so that steam would sync savegame data.
I will retry with next Wine Staging release, but currently revert the registry patches as the visual glitches are too distracting: Many surfaces are way too dark now, many almost black with a few specs of hard to see pixels and patterns.
Gentoo: x11-drivers/nvidia-drivers-384.90:0/384
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #46 from Kai Krakow kai@kaishome.de --- I'm now on wine-staging 2.20 and performance seems to have improved.
I no longer see the tessellation bug on monsters, and in areas with such monster and previously bad performance, things have improved a lot. So the most annoying visual bug is gone and performance has even improved here.
I still see visual glitches like missing textures around cave entrances and the opaque texture bug. I also see performance degradation around such areas. But at least the performance degradation seems no longer be permanent, or better saying it has much less impact. The game still slows down over a longer period of time, but it is much better now.
Overall performance of the game has improved, even at higher detail settings. Physic simulation still has a big impact on time progression in the game: FPS go down, and time seems to run much slower.
Also, rain seems to have a much lower performance impact now.
During first entering new areas, I see a lot of short freezes, probably due to some shader compiling. I guess this new behavior also has to do with the better performance. FWIW, I no longer use the shader parameter caching patch (it was incompatible with 2.20).
For the numbers:
I still have no FPS numbers as debug flags "+fps" simply don't show fps in the log while the game is running (but it's showing up while Steam is starting up).
Interestingly, while the game feels overall smoother now, GPU usage is even lower (around 50% instead of around 65%). Also, the game no longer seems to overshoot time progression during phases where I saw high fps (what felt like 60fps): Fights are no longer feeling like time lapse in high fps situations.
I'm pretty confident that fixing the remaining visual glitches may also improve performance. I don't see how that relates to each other but previous updates show improvement on that matter. Afterwards, if figuring out why GPU usage is so low (CPU usage is also not maxed out, not a single core) there should be a good chance to get high fps out of this game.
BTW: Some monsters are still invisible, most of them become visible as soon as they die.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #47 from Shmerl shtetldik@gmail.com --- (In reply to Kai Krakow from comment #46)
I no longer see the tessellation bug on monsters, and in areas with such monster and previously bad performance, things have improved a lot. So the most annoying visual bug is gone and performance has even improved here.
Are you sure about that? I tested recently (Wine master with needed staging patches), and bug 43828 was still there.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #48 from Kai Krakow kai@kaishome.de --- Y(In reply to Shmerl from comment #47)
(In reply to Kai Krakow from comment #46)
I no longer see the tessellation bug on monsters, and in areas with such monster and previously bad performance, things have improved a lot. So the most annoying visual bug is gone and performance has even improved here.
Are you sure about that? I tested recently (Wine master with needed staging patches), and bug 43828 was still there.
Yes, that problem is gone for me in wine-staging. It was there in 2.19, gone in 2.20. I still have 2.19 installed, so I could cross-check.
Packages were built using Gentoo portage.
Linux jupiter 4.13.12-ck #5 SMP PREEMPT Tue Nov 14 23:31:31 CET 2017 x86_64 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz GenuineIntel GNU/Linux
$ equery l nvidia-drivers wine-staging * Searching for nvidia-drivers ... [IP-] [ ] x11-drivers/nvidia-drivers-384.90:0/384
* Searching for wine-staging ... [IP-] [ ] app-emulation/wine-staging-2.19:2.19 [I-O] [ ] app-emulation/wine-staging-2.20:2.20
I bumped the version from 2.19 to 2.20 in my own local overlay. Version 2.20 is not yet released in official portage.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #49 from Shmerl shtetldik@gmail.com --- I just tested TW3 with Wine mater and minimal rebased staging patches + invisible surfaces patch using newest Mesa master, and noticed a regression (fps was reduced almost in half from before), and it also introduced some weird 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 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)
I'll probably open a Mesa bug about this regression.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #50 from Kai Krakow kai@kaishome.de --- (In reply to Shmerl from comment #49)
I just tested TW3 with Wine mater and minimal rebased staging patches + invisible surfaces patch using newest Mesa master, and noticed a regression (fps was reduced almost in half from before), and it also introduced some weird 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 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)
I'll probably open a Mesa bug about this regression.
Aside from the other problems I described, I'm seeing flickering of some single objects lately with nvidia blob, also low fps (as before). Maybe related?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #51 from Shmerl shtetldik@gmail.com --- (In reply to Kai Krakow from comment #50)
Aside from the other problems I described, I'm seeing flickering of some single objects lately with nvidia blob, also low fps (as before). Maybe related?
May be what you see is bug 43786? It's something else than what I described above. What I see in Mesa master now is a flickering of the whole screen and it doesn't happen with older Mesa. I'll try to narrow it down to specific Mesa changes.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #52 from Kai Krakow kai@kaishome.de --- (In reply to Shmerl from comment #51)
(In reply to Kai Krakow from comment #50)
Aside from the other problems I described, I'm seeing flickering of some single objects lately with nvidia blob, also low fps (as before). Maybe related?
May be what you see is bug 43786? It's something else than what I described above. What I see in Mesa master now is a flickering of the whole screen and it doesn't happen with older Mesa. I'll try to narrow it down to specific Mesa changes.
No, not bug 43786: I'm seeing it when standing still, even during dialogs. In the background I see some single objects flickering with the current fps rate. It's rare, and it's mostly with static objects like tables or flower pots. I never saw that in the main quests, only in the DLC quests (thus, new areas not part of the main game)...
I never saw textures flickering: Either they are completely missing (which seems to affect fps: the engine starts to render a lot of useless and strange things from even far behind), or they are completely opaque (like cave entries and dimmed corners). Tho, depending on viewing angle or distance the "missing" textures sometimes become visible. But they never started flickering, even when at the sweet spot between visible or invisible.
https://bugs.winehq.org/show_bug.cgi?id=42592
Anders Dahlberg dahlberg@lysator.liu.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dahlberg@lysator.liu.se
--- Comment #53 from Anders Dahlberg dahlberg@lysator.liu.se --- Created attachment 59845 --> https://bugs.winehq.org/attachment.cgi?id=59845 operf while running Witcher3
Hi,
Not sure if this performance data is useful or not, but captured using oprofile while running Witcher3. Few minutes running around in Skellige.
FPS between 8 and 26 but mainly within 15-22 measured using glxosd while doing above.
My system:
Ryzen 7 1700 MSI Geforce GTX 1080 using 387.34 driver
Let me know if there are any other data/measurements I can help with! :-)
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #54 from Anders Dahlberg dahlberg@lysator.liu.se --- Created attachment 59847 --> https://bugs.winehq.org/attachment.cgi?id=59847 operf while running Witcher3, now with symbol information
Hi again,
Same as above, but now with symbol-information. Wine-staging 2.20 built using -03 -g with all wine-staging patches applied.
https://bugs.winehq.org/show_bug.cgi?id=42592
Ehvis wine@velds.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@velds.net
--- Comment #55 from Ehvis wine@velds.net --- I saw similar numbers using oprofile. However, the function name it showed me for the high load in wined3d.dll was either shader_glsl_generate_ffp_fragment_shader or shader_arb_load_constants_f. Not sure if that means anything though.
https://bugs.winehq.org/show_bug.cgi?id=42592
KiaraNyasha mihaahr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mihaahr@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=42592
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=42592
Graham libgradev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |libgradev@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
KG krzysztofg87@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krzysztofg87@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #56 from Shmerl shtetldik@gmail.com --- Created attachment 60428 --> https://bugs.winehq.org/attachment.cgi?id=60428 Updated don't pin large buffers patch applicable to Wine master
Since staging fell behind too much, and proposed updated staging patch doesn't apply to Wine master either, I'm attaching a modified patch that works.
https://bugs.winehq.org/show_bug.cgi?id=42592
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #60428|0 |1 is obsolete| |
--- Comment #57 from Shmerl shtetldik@gmail.com --- Created attachment 60429 --> https://bugs.winehq.org/attachment.cgi?id=60429 Updated don't pin large buffers patch applicable to Wine master
Since staging fell behind too much, and proposed updated staging patch doesn't apply to Wine master either, I'm attaching a modified patch that works.
(+ build fixes).
https://bugs.winehq.org/show_bug.cgi?id=42592
oiaohm oiaohm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm@gmail.com
--- Comment #58 from oiaohm oiaohm@gmail.com --- Users of Witcher 3 have report this kind of patch like Shmerl did causing hard lockups and the mainline running slow not having hard lockups. So these patches are not where near right.
https://github.com/wine-mirror/wine/blob/master/dlls/wined3d/buffer.c#L1416
Really desc->access need to used as what is in master.
The problem is the FIXME("Ignoring access flags (pool).\n"); message. Rough implementing has caused side effects now that wine is starting to implement pool that shows up that the FIXME is gone a lot more care messing with the desc->access value has to be done.
So we need test results of Witcher3 against master unmodified.
Shmerl you have stopped all over the value of desc->access in master this is not on. You patch is worse as you have moved even more code without any valid need.
If there is still a performance problem with master you need to perform bytewise operations on desc-access so you don't nuke other flags combination that are in the access value.
shmerl read resource_access_from_pool carefully there are currently 3 modes. You magically reduce this down to two of course this is going to have adverse side effects. So you do need to be checking what the heck the desc->access value is before messing with it and using the desc->access value as part of your logic.
There are most likely values of desc->access that say do not touch me or I will cause adverse side effects. As pool defines are implemented desc->access becomes far more of a hazard to stomp all over. While pool was not implement you could kind of run rough shot.
So the patch you did shmerl fail to fix Witcher just causes another defect because the patch design is wrong. This is the problem with forwards porting stuff from staging is it was stuck in staging because it wrong and need to be revised and re-implemented differently. Patch need to go back and be redesigned.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #59 from Shmerl shtetldik@gmail.com --- (In reply to oiaohm from comment #58)
Users of Witcher 3 have report this kind of patch like Shmerl did causing hard lockups and the mainline running slow not having hard lockups.
Are these lockups same as freeze in #43872?
And how do you propose to set the flags in this case (based on the desc->access parameter)?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #60 from oiaohm oiaohm@gmail.com --- Cannot find that bug number but I can tell you this is a case that mainline wine might be running the program slow but there is no lock-up. Only after you do this incorrect form of patch does lock-up come. So flag alteration is causing harm.
If I was doing this I would not be creating a new pool entry.
enum wined3d_pool pool;<< this line is the start wrong total wrong.
First no TRACE or FIXME or WARN in your code to it cannot be debugged.
So the first thing that need adding is a TRACE on desc->access
TRACE("desc->access %d",desc->access); straight after existing TRACE. So we have the raw value before we play with anything. Next a new DWORD access; This would be straight under HRESULT hr; This is out scratch pad.
Due to prior being brute force I don't know what you were setting/unsetting and neither do you. Because I have no clue what access values you have been crushing/needing to crush I cannot write correct patch only provide guide.
access=desc->access; if(access== some filter so you don't in fact hit everything) if (desc->byte_width > 0x10000) {
Some bitwise operator/operators here setting/unsetting bits area1.
TRACE("modified desc->access %d",access); } else { Some bitwise operator/operators here setting/unsetting bits area2
TRACE("modified desc->access %d",access); }
Final bit is hook in the change. if (FAILED(hr = buffer_init(object, device, desc->byte_width, desc->usage, WINED3DFMT_UNKNOWN, access, desc->bind_flags, data, parent, parent_ops)))
Next you will be needing bytewise operations.
https://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-...
Due to prior being brute force I don't know what you were setting/unsetting.
Like area1 being desc->byte_width > 0x10000
WINED3D_RESOURCE_ACCESS_GPU does this bit need to be set. if to be set is access |=WINED3D_RESOURCE_ACCESS_GPU;
Do WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP need to be unset here if so access &= ~(WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP);
Are there any other bits that should be turned off.
In fact WINED3D_RESOURCE_ACCESS_GPU might be your test if you should or should not.
Area2 that is else to desc->byte_width > 0x10000 is simpler access |=WINED3D_RESOURCE_ACCESS_GPU | WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP This turns those 3 bits on.
Are there any other bits that should be turned off.
Even so this patch is still not going to be suitable for mainline but with the traces and careful control of what bits you are messing with will provide some information to attempt to back trace where this was set wrong in the first place.
My rough calc says you could need to make over 16 new patches based of what I just wrote to attempt to work out exactly what bit values are needing to be modified. Modify only the correct values might cure the lockup problem.
Please take a close look at the pool system memory mode. case WINED3D_POOL_SYSTEM_MEM
return WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_MAP
You brute force was override this. So this now means WINED3D_POOL_SYSTEM_MEM requests are being given WINED3D_RESOURCE_ACCESS_GPU so sent to a GPU allocation as well most likely a bad thing and could cause nice lockups as applications attempt to allocate memory to avoid over filling the GPU and the old patches send them to the GPU anyhow.
This is why I am highy suspect that you should be filtering if WINED3D_RESOURCE_ACCESS_GPU is set if (access & WINED3D_RESOURCE_ACCESS_GPU) kind of thing before doing any change and if that is the case you don't need to be setting that bit again.
So somewhat correct patch is going to look absolutely different.
Reality is I have a lot of guess work because no data collected on what you were really changing so its impossible for someone without the game to correct the patch because not enough data.
Yes I know installing trace entries can slow thing down but at least if you had submit a lot with the extra value information someone could attempt to create more correct patch or attempt to locate where the incorrect values are coming from.
There are a lot of patches in staging lacking instrumentation like TRACE and FIXME and WARN entries. This means no data for anyone else to provide somewhat corrected patches.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #61 from Henri Verbeet hverbeet@gmail.com --- Well, the wined3d_pool enum no longer exists in current Wine git, so any hack based on that will run into issues. If you want to do a hack, I'd suggest starting with not setting WINED3D_RESOURCE_ACCESS_CPU in d3d11's d3d_buffer_init(), unless "Usage" is D3D11_USAGE_STAGING, in which case you don't want WINED3D_RESOURCE_ACCESS_GPU. This is also an area that's currently seeing active development though; any hack is likely to get broken again relatively soon.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #62 from oiaohm oiaohm@gmail.com --- (In reply to Henri Verbeet from comment #61)
Well, the wined3d_pool enum no longer exists in current Wine git, so any hack based on that will run into issues. If you want to do a hack, I'd suggest starting with not setting WINED3D_RESOURCE_ACCESS_CPU in d3d11's d3d_buffer_init(), unless "Usage" is D3D11_USAGE_STAGING, in which case you don't want WINED3D_RESOURCE_ACCESS_GPU. This is also an area that's currently seeing active development though; any hack is likely to get broken again relatively soon.
I am guessing by this is retest with master to see if performance fault still exist or has been fixed by all the changes.
This was also something I was suspecting change way too many values.
So correct might only be turn on the WINED3D_RESOURCE_ACCESS_MAP flag and leave everything alone with like a ten foot barge pole and see if that fixes the performance problem.
Also from what you saying alteration should be outside wined3d and up in the direct x libraries? This would also limit area of effect.
Really this is why I was saying key part collect more data on what the program is doing to attempt to work out why in heck it so slow and possible make a test case that abuses wine that way so it can be fixed.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #63 from KG krzysztofg87@gmail.com --- In wine master performance problem still exist. I have been doing some experiments with buffer hack and this part of perfomance hack can be restricted to
desc->bind_flags with WINED3D_BIND_CONSTANT_BUFFER
Anyway any kind of this hack cause some other performance problem (possiby on Nvidia only).
On my GTX 1060: In vanilla master I have ~80% GPU usage but 3-5 FPS, With buffer hack ~40-60% GPU usage and ~20 FPS and CPU cores rarely get 100%.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #64 from oiaohm oiaohm@gmail.com --- (In reply to KG from comment #63)
In wine master performance problem still exist.
You need to include the last commit value. So someone reading this know up to when was tested.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #65 from Shmerl shtetldik@gmail.com --- (In reply to Henri Verbeet from comment #61)
Well, the wined3d_pool enum no longer exists in current Wine git, so any hack based on that will run into issues. If you want to do a hack, I'd suggest starting with not setting WINED3D_RESOURCE_ACCESS_CPU in d3d11's d3d_buffer_init(), unless "Usage" is D3D11_USAGE_STAGING, in which case you don't want WINED3D_RESOURCE_ACCESS_GPU. This is also an area that's currently seeing active development though; any hack is likely to get broken again relatively soon.
I applied that method above to regular Wine master, setting access mask WINED3D_RESOURCE_ACCESS_GPU | WINED3D_RESOURCE_ACCESS_MAP in d3d_buffer_init. Performance is pretty bad, just around 20fps instead of 40 like before.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #66 from KG krzysztofg87@gmail.com --- 2936f3f9bb Release 3.2.
Buffer Hack no longer needed but performance is still very poor on Nvidia.
Now I get ~15-20 FPS (max 30 when looking to sky), 40% GPU usage and almost all time 2 CPU cores are at 100%. 1700X - GTX 1060.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #67 from Anders Dahlberg dahlberg@lysator.liu.se --- With official Wine 3.2 and recent builds from master I now get:
Game won't launch, just a black screen, hangs, and the following error message: 00c4:err:seh:setup_exception stack overflow 1712 bytes in thread 00c4 eip 000000007bc65c29 esp 000000003b020f60 stack 0x3b020000-0x3b021000-0x3b220000
Official 3.1 works, but with the usual 3-4fps performance.
Haven't tried on a fresh wineprefix (yet) - haven't had the time.
R7 1700 on KDE Neon (~Ubuntu) with 4.15.3-041503-generic x86_64 GTX 1080 with 387.34
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #68 from Anders Dahlberg dahlberg@lysator.liu.se --- (In reply to Anders Dahlberg from comment #67)
With official Wine 3.2 and recent builds from master I now get:
Game won't launch, just a black screen, hangs, and the following error message: 00c4:err:seh:setup_exception stack overflow 1712 bytes in thread 00c4 eip 000000007bc65c29 esp 000000003b020f60 stack 0x3b020000-0x3b021000-0x3b220000
Official 3.1 works, but with the usual 3-4fps performance.
Haven't tried on a fresh wineprefix (yet) - haven't had the time.
R7 1700 on KDE Neon (~Ubuntu) with 4.15.3-041503-generic x86_64 GTX 1080 with 387.34
Scratch that.
3.0 works fine with 3-4fps. 3.1 loads and shows the menu, but won't show any cut scenes - hangs with the following out put when pressing continue:
0171:fixme:dxgi:dxgi_swapchain_Present1 Unimplemented sync interval 1.
3.2 as above, won't even load menu.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #69 from Shmerl shtetldik@gmail.com --- (In reply to Anders Dahlberg from comment #68)
3.2 as above, won't even load menu.
Sounds like a separate issue - please open a new bug.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #70 from Anders Dahlberg dahlberg@lysator.liu.se --- (In reply to Shmerl from comment #69)
(In reply to Anders Dahlberg from comment #68)
3.2 as above, won't even load menu.
Sounds like a separate issue - please open a new bug.
https://bugs.winehq.org/show_bug.cgi?id=44551
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #71 from Anders Dahlberg dahlberg@lysator.liu.se --- Bug above seems to be solved in latest master. Did a fresh build on 7be8bea shlwapi: Don't attempt to un-expand ComputerName in PathUnExpandEnvStrings.
FPS vary between 4-7fps so more than 100% improvement compared to earlier master-versions that ran 1-4fps. Trending in the right direction! :-)
https://bugs.winehq.org/show_bug.cgi?id=42592
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57530|0 |1 is obsolete| |
--- Comment #72 from Józef Kucia joseph.kucia@gmail.com --- Created attachment 60570 --> https://bugs.winehq.org/attachment.cgi?id=60570 Small buffers hack
You can try to use the attached hack instead of the old buffer pool hack.
https://bugs.winehq.org/show_bug.cgi?id=42592
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|The Witcher 3 has poor |The Witcher 3 has poor |performance |performance (buffer pools | |are ignored)
https://bugs.winehq.org/show_bug.cgi?id=42592
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b6f917b1023ea2b9591f6b72d34 | |ff2afa34bd914 Resolution|--- |FIXED Summary|The Witcher 3 has poor |The Witcher 3 has poor |performance (buffer pools |performance (buffer access |are ignored) |flags are ignored) Status|UNCONFIRMED |RESOLVED
--- Comment #73 from Józef Kucia joseph.kucia@gmail.com --- Buffer access flags are correctly handled in the current git. Resolving as fixed.
https://source.winehq.org/git/wine.git/?a=commit;h=b6f917b1023ea2b9591f6b72d...
We are still working on some performance improvements when it comes to buffer maps but those should be tracked as a separate bug.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #74 from tt_1 herrtimson@yahoo.de --- Anyone out there has a Polaris 11 based Card and got it working in playable frames per seconds? Using amdgpu from kernel-4.14.21, mesa-17.3.5, libdrm-2.4.89, and it is somewhat 1-2 fps with an rx 550 and wine-3.2 - this plus the buffer patch gives me sort of deadlocks, black screen which can't be killed with keyboard.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #75 from mirh mirh@protonmail.ch --- Buffer maps.. Is that any related to the new wine-PBA work?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #76 from Shmerl shtetldik@gmail.com --- (In reply to Józef Kucia from comment #73)
Buffer access flags are correctly handled in the current git. Resolving as fixed.
We are still working on some performance improvements when it comes to buffer maps but those should be tracked as a separate bug.
Should I open a new bug? Currently, TW3 performance without the new hack is still around 12 fps with RX 480 on 1920x1200. With the new hack, it's around 20+ fps, better but far from what it was with the old hack.
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #77 from Shmerl shtetldik@gmail.com --- Is bug 44315 about this?
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #78 from Anders Dahlberg dahlberg@lysator.liu.se --- (In reply to Józef Kucia from comment #72)
Created attachment 60570 [details] Small buffers hack
You can try to use the attached hack instead of the old buffer pool hack.
Just to confirm: Ryzen 7 w GTX1080, with patch above on 7be8bea shlwapi I now see ~20 fps compared to ~7 fps with clean master. Back to ~same as wine-staging 2.21 performance. :-)
https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #79 from Kai Krakow kai@kaishome.de --- I can confirm that the latest patches make a much smoother game experience, even in cities. So far, it looks much better with my system than the original staging patches.
I created a branch from the d3d patches ontop of 3.2 so I can apply them easily to the Gentoo ebuild. The branch also includes the small buffers hack.
System: NVIDIA GTX 1050 Ti
Github: https://github.com/kakra/wine/tree/patches-3.2/wined3d
Export patches into one series file:
# Add my github repo as remote (needed only once) $ git remote add kakra https://github.com/kakra/wine
# Checkout and export $ git checkout patches-3.2/wined3d $ git format-patch --stdout wine-3.2 | sudo tee /etc/portage/patches/app-emulation/wine-vanilla-3.2/wined3d.patch
According to nvidia-smi, GPU usage is still peaking at around 55%, so there's still potential for improvement.
If you don't want to wait for 3.3 or do not want to use master, you can use above instruction to export and apply my patches to your 3.2 package build. However, I don't know how to do that in DEB or RPM based distribution, I only know there should be a relatively simple way.
https://bugs.winehq.org/show_bug.cgi?id=42592
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #80 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.3.
-
wine-bugs＠winehq.org