https://bugs.winehq.org/show_bug.cgi?id=43118
Bug ID: 43118 Summary: Absurdly high shader_arb_select runtime usage in WoW Product: Wine Version: 2.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: mine809@gmail.com Distribution: ---
Created attachment 58320 --> https://bugs.winehq.org/attachment.cgi?id=58320 Symbol annotated profiling report from OProfile
When running World of Warcraft: Legion (Version 7.2.0.24015) using the D3D11 renderer, framerates are severly limited by the time taken in shader_arb_select.
I am using a GTX970 with the proprietary NVidia drivers.
Below I have attached the symbol annotated samples produces by oprofile, along with annotated source of arb_program_shader.c showing that fragment shader binding seems to be the core issue.
Please do not hesistate to ask for any other information, I'll gladly help out.
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #1 from Emil Lauridsen mine809@gmail.com --- Created attachment 58321 --> https://bugs.winehq.org/attachment.cgi?id=58321 Sample count annotated arb_program_shader.c
https://bugs.winehq.org/show_bug.cgi?id=43118
Emil Lauridsen mine809@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mine809@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #2 from Emil Lauridsen mine809@gmail.com --- Created attachment 58344 --> https://bugs.winehq.org/attachment.cgi?id=58344 OPReport symbols after clang compile
I've shifted to building with clang to resolve an issue with the 64-bit version of the game. This appearantly improved the granularity of the symbols listing from oprofile.
The game appears to do a lot of shader building, something which should probably hit a cache somewhere.
Does this ring any bells for anybody with knowledge of the wine d3d implementation?
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- (In reply to Emil Lauridsen from comment #2)
Does this ring any bells for anybody with knowledge of the wine d3d implementation?
Mostly just "You get to keep all the pieces if it breaks." and "This is why I avoid proprietary drivers.", I'm afraid.
We keep arb_program_shader.c around because some people find it useful and it's not too obnoxious to keep around, but it isn't really being maintained and may be broken in subtle or not so subtle ways at any given time. Likewise, a significant amount of time is spent in the driver, and without driver source you're left making guesses at what might be going on.
That said, you may want to check whether the issue is that compilation time of individual shaders is unreasonably large, or if instead the issue is that we're generating an unreasonable number of shader variants. In the latter case, "shader_data->num_gl_shaders" in e.g. find_arb_vshader() being large would be a hint in that direction.
Also, are you sure you're actually getting the Direct3D 11 renderer? ARB program shaders don't implement shader model 4 and up. Somewhat related, how "clean" is that profile? I see references to both shader_glsl_select() and shader_arb_select() in there, which shouldn't normally happen within the same process.
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #4 from Emil Lauridsen mine809@gmail.com --- I'm 98% sure the game is actually running in D3D11 mode, there's a noticeable difference in how smooth/stable the two renderers run. The profile should be as clean as I can get it, I attach to the running process after launching wine and logging in to the game.
I'll take a look at num_gl_shaders, and also test if nouveau behaves differently.
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #5 from Emil Lauridsen mine809@gmail.com --- Hmm, this is odd. It does not appear that the arb path is actually used, even though it ends up in the profile data. I must be doing something wrong somewhere along this process.
The number of gl shaders for each d3d shader is around 1 for the majority of shaders used in WoW, so I assume the problem is not with many variations of the same shader. It could be that WoW is creating and destroying shaders quite frequently, and thus not behaving all that favorably with the way wined3d handles shaders. Does that sound reasonable?
https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #6 from Emil Lauridsen mine809@gmail.com --- Okay, color me intrigued.
The issue appeared to be CSMT... Disabling it seemingly improved performance in many scenarios, and the profile spread seems a lot more reasonable:
samples| %| ------------------ 1379086 38.4584 anon (tgid:12143 range:0x140001000-0x141016fff) 973754 27.1550 libnvidia-glcore.so.381.22 449930 12.5471 wined3d.dll.so
With the top one probably being the game (please correct me if I'm wrong), then the proprietary GL impl and then wined3d in third place.
Performance is seemingly rather close to native windows performance, although I have yet to test performance doing raiding, which is more intensive, but initial result is promising.
https://bugs.winehq.org/show_bug.cgi?id=43118
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #7 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.11?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla