http://bugs.winehq.org/show_bug.cgi?id=33814
Bug #: 33814 Summary: Performance regression in 1.6-rc2 Product: Wine Version: 1.6-rc2 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: tdsbug@gmail.com Classification: Unclassified Regression SHA1: ffc9f535eb7817ea4cd0d0657471e61a9813debd
There is huge framerate drop in Ground Control
ffc9f535eb7817ea4cd0d0657471e61a9813debd is the first bad commit commit ffc9f535eb7817ea4cd0d0657471e61a9813debd Author: Henri Verbeet hverbeet@codeweavers.com Date: Fri Jun 14 09:07:12 2013 +0200
wined3d: Handle pre-transformed vertices in the GLSL vertex pipe.
This also avoids a fallback to drawStridedSlow().
:040000 040000 a2d808d529d1695a844485a194fc8db77b699b2d 2052d3dc5293fb46c01e5bb1bbca101b9072323d M dlls
Nvidia 210, 319.23 driver Resolution changes, graphics options, nvidia-settings etc have no effect on this framerate drop.
WINEDEBUG=+d3d log: https://docs.google.com/file/d/0ByuikmI4uhzXLXVuaW5JU2tNeWs/edit?usp=sharing
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2013-06-16 06:16:58 CDT --- Does this happen with the demo mentioned in bug 33807?
http://bugs.winehq.org/show_bug.cgi?id=33814
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #2 from tdsbug@gmail.com 2013-06-16 08:15:06 CDT --- Yes, it does happen. BTW - it's a full game :)
http://bugs.winehq.org/show_bug.cgi?id=33814
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Performance regression in |Ground Control: poor fps |1.6-rc2 |performance
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #3 from Henri Verbeet hverbeet@gmail.com 2013-06-17 13:31:20 CDT --- Does using WINEDEBUG=-all help? It looks like buffer maps are more expensive in debug contexts, and the commit in question allows VBOs to be used for more draws.
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #4 from tdsbug@gmail.com 2013-06-17 13:56:37 CDT --- (In reply to comment #3)
Does using WINEDEBUG=-all help? It looks like buffer maps are more expensive in debug contexts, and the commit in question allows VBOs to be used for more draws.
Yes, WINEDEBUG=-all does noticeabley increase fps, but it's still much slower from what it used to be.
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2013-06-18 08:41:07 CDT --- Created attachment 44848 --> http://bugs.winehq.org/attachment.cgi?id=44848 patch
The application seems to draw the entire scene using lots of d3d_device7_DrawPrimitive() calls with small vertex counts (< 30). That's sub-optimal. This results in lots of small buffer maps, and I have the impression that maps in general are relatively expensive on the proprietary nvidia driver. The attached path seems to help for me, although it may be too specific to the application and driver combination to be of general use.
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #6 from Axper Jan tdsbug@gmail.com 2013-06-18 09:05:51 CDT --- The patch fixes the issue for me as well.
http://bugs.winehq.org/show_bug.cgi?id=33814
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, patch URL| |http://www.fileplanet.com/1 | |56136/150000/fileinfo/Groun | |d-Control-%5BFree-Game%5D
http://bugs.winehq.org/show_bug.cgi?id=33814
goodgod261 goodgod261@wp.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |goodgod261@wp.pl
--- Comment #7 from goodgod261 goodgod261@wp.pl 2013-06-29 18:53:19 CDT --- Soldat is affected too. The patch works for me.
http://bugs.winehq.org/show_bug.cgi?id=33814
Jarkko K jarkko_korpi@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarkko_korpi@hotmail.com
--- Comment #8 from Jarkko K jarkko_korpi@hotmail.com --- I installed the demo. And run it once. Then I did another run with maximum settings I could find.
The maximmum resolution was 1024x1080 (I think),maxed draw distance and quality ect.
Game saw correctly my graphic card, 7800 series. The mouse is very responsive game menus, but in game the fps gets poor.
But it feels that if you look sky fps is good but if you look at the hills, the mouse and fps gets poor (didnt measure).
I didnt try any patch into wine, but without it maxed graphics the gameplay isnt smooth with ati 7870. Which should be powerfull enough for this game.
I installed it via 1.7.18 but I think I run it via 1.7.17
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #9 from Jarkko K jarkko_korpi@hotmail.com --- I rerun the game once more, this time tutorial and I assume that the same game settings are valid which I used before, th game is non-playable. Your mouse movement is so slow. It takes around 1s to move your mouse 1-2 inches. I did basic debug and only lines I find interesting were:
fixme:ddraw:DirectDrawEnumerateExA flags 0x00000006 not handled fixme:ddraw:ddraw7_Initialize Ignoring guid {aeb2cdd4-6e41-43ea-941c-8361cc760781}. fixme:ddraw:ddraw_surface7_Flip Ignoring flags 0x1. fixme:d3d_surface:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit. fixme:ddraw:ddraw7_FlipToGDISurface iface 0x13cfe0 stub!
There might also be some graphic errors, but not sure because I haven't seen how the game should look like.
But I confirm that this game is unplayable at the state it is without patch.
http://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #10 from Axper Jan tdsbug@gmail.com --- Graphical errors is probably Bug #33807
https://bugs.winehq.org/show_bug.cgi?id=33814
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #11 from joaopa jeremielapuree@yahoo.fr --- Still a bug in current wine?
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #12 from Henri Verbeet hverbeet@gmail.com --- Does this still happen? If it does, does it work any better with the Nouveau driver?
I'm fairly sure this is specific to the nvidia driver and the way it implements buffer maps, but no longer have any setups which use the proprietary nvidia driver.
https://bugs.winehq.org/show_bug.cgi?id=33814
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #13 from winetest@luukku.com --- I can't get it started or I didnt wait enough.
fixme:ddraw:d3d_device_create Only one Direct3D device per DirectDraw object supported. fixme:ddraw:ddraw_surface_create Application wants to create rendering target in system memory, using video memory instead
These are spammed at console. It shows some videoclip and after that black screen.
wine 2.0rc4 and staging 2.0rc4.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- The game runs visually fine for me with Intel graphics on Wine 2.9, I also tested 1.4.1 and it looks the same.
With the proprietary NVIDIA driver I was not able to see the game, I get a black screen in 2.9 and all the way back to 1.4.1 (with all latest stable versions tested). I would assume this to be an NVIDIA problem, if any logs are required I can provide.
Not sure if I can say this is fixed because comment 0 says it is NVIDIA specific and I can't test.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #15 from Henri Verbeet hverbeet@gmail.com --- (In reply to Bruno Jesus from comment #14)
With the proprietary NVIDIA driver I was not able to see the game, I get a black screen in 2.9 and all the way back to 1.4.1 (with all latest stable versions tested). I would assume this to be an NVIDIA problem, if any logs are required I can provide.
That's odd, the issue was originally reported against 1.6-rc2. Any FIXMEs/ERRs?
https://bugs.winehq.org/show_bug.cgi?id=33814
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #16 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 58274 --> https://bugs.winehq.org/attachment.cgi?id=58274 standard output log
Attached is the console log for Wine 2.9.
NVIDIA 940M, driver version 375.39.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #17 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 58275 --> https://bugs.winehq.org/attachment.cgi?id=58275 intel log
Intel log for comparison, for me they are the same.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #18 from Henri Verbeet hverbeet@gmail.com --- (In reply to Bruno Jesus from comment #17)
Intel log for comparison, for me they are the same.
Well, "fixme:ddraw:d3d_device_create Only one Direct3D device per DirectDraw object supported." is different. Could you attach a +ddraw,+d3d,+seh,+tid log? It's probably best to do that with csmt disabled.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #19 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 58276 --> https://bugs.winehq.org/attachment.cgi?id=58276 +ddraw,+d3d,+seh,+tid
Log as requested, full size: 175Mb
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #20 from Henri Verbeet hverbeet@gmail.com --- That log doesn't seem to have that particular fixme. That's odd too, but perhaps it's not related then.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #21 from Bruno Jesus 00cpxxx@gmail.com --- That line seems random, depending on how I dismiss the intro videos by pressing ESC. I'm trying to install noveau, will report on success.
https://bugs.winehq.org/show_bug.cgi?id=33814
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #22 from Józef Kucia joseph.kucia@gmail.com --- I can reproduce the original issue here.
OpenGL renderer string: GeForce GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 378.13 wine-2.9
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #23 from joaopa jeremielapuree@yahoo.fr --- Is still a bug in current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #24 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.0-rc3?
https://bugs.winehq.org/show_bug.cgi?id=33814
andy andy86@fastwebnet.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andy86@fastwebnet.it
--- Comment #25 from andy andy86@fastwebnet.it --- I think this bug still occur with wine-5.21 because I've run into a quite similar bug (see bug 50093) and I also use proprietary NVIDIA driver.
Attacched patch is too old to apply in current wine, I try, with my basilar skills, to rebase it for current wine but I've just run into a GL_ERROR and in the resulting crash.
Also the first bad commit is too old to be build with updated libraries.
I try to run wine in a live in order to test it with free drivers but without success.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #26 from andy andy86@fastwebnet.it --- I've managed to test for bug #50093 in a nouveau drivers and, at least that bug, still existing also with it.
So I don't understand anymore if this bug is related or not.
https://bugs.winehq.org/show_bug.cgi?id=33814
Steve Schnepp steve.schnepp@pwkf.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |steve.schnepp@pwkf.org
--- Comment #27 from Steve Schnepp steve.schnepp@pwkf.org --- Created attachment 73923 --> https://bugs.winehq.org/attachment.cgi?id=73923 gc.exe_one-frame
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #28 from Steve Schnepp steve.schnepp@pwkf.org --- I'm also seeing that bug with a recent 8.0rc4 and
Vendor: Intel (0x8086) Device: Mesa Intel(R) HD Graphics 500 (APL 2) (0x5a85) Version: 20.3.5 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2
A perf recording showed that most of the time is spend in wined3d_device_context_map, and indeed when I launch it with
WINEDEBUG="+fps,+timestamp,+pid,+d3d,+ddraw,+wgl,+opengl"
It seems that it is indeed many times in the same frame.
26138.298:0020:0024:trace:d3d:wined3d_resource_map resource 0A024060, sub_resource_idx 0, map_desc 0021E30C, box (62240, 0, 0)-(62400, 1, 1), flags > 26138.298:0020:0024:trace:d3d:wined3d_resource_map resource 0A024060, sub_resource_idx 0, map_desc 0021E30C, box (62400, 0, 0)-(62560, 1, 1), flags > 26138.298:0020:0024:trace:d3d:wined3d_resource_map resource 0A024060, sub_resource_idx 0, map_desc 0021E30C, box (62560, 0, 0)-(62720, 1, 1), flags > 26138.298:0020:0024:trace:d3d:wined3d_resource_map resource 0A024060, sub_resource_idx 0, map_desc 0021E30C, box (62720, 0, 0)-(62880, 1, 1), flags > 26138.298:0020:0024:trace:d3d:wined3d_resource_map resource 0A024060, sub_resource_idx 0, map_desc 0021E30C, box (62880, 0, 0)-(63040, 1, 1), flags > ...
So the function is called many times with some adjacent boxes.
Full log for a frame is attached as https://bugs.winehq.org/attachment.cgi?id=73923
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #29 from Steve Schnepp steve.schnepp@pwkf.org --- Created attachment 73954 --> https://bugs.winehq.org/attachment.cgi?id=73954 0001-ddraw-Simple-buffer-for-identical-DrawPrimitives-TRI.patch
Here is a patch that fixes that bug for me.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #30 from Steve Schnepp steve.schnepp@pwkf.org --- Unfortunatly, while this works marvelously well on desert maps, it doesn't do as well on jungle and maps woth a base.
I guess it is because they are much more texture heavy, and batching cannot happen as successfully.
More exploration needed it seems ;-)
https://bugs.winehq.org/show_bug.cgi?id=33814
Steve Schnepp steve.schnepp@pwkf.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73954|0 |1 is obsolete| |
--- Comment #31 from Steve Schnepp steve.schnepp@pwkf.org --- Created attachment 73961 --> https://bugs.winehq.org/attachment.cgi?id=73961 0001-ddraw-Simple-buffer-for-identical-DrawPrimitives-TRI.patch
Updated the patch, it does now work with any number of vertices.
It therefore helps a lot with trees & bases as they have usually 5-6 vertices int the FAN.
Enabling the patch is still done via
WINEDEBUG=+ddraw_buffer
https://bugs.winehq.org/show_bug.cgi?id=33814
Steve Schnepp steve.schnepp@pwkf.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73923|0 |1 is obsolete| |
--- Comment #32 from Steve Schnepp steve.schnepp@pwkf.org --- Created attachment 73962 --> https://bugs.winehq.org/attachment.cgi?id=73962 flush vertices count
A trace of all the flush done. There's quite a huge number with multiple inside, but those that couldn't be optimized away are still here.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #33 from Steve Schnepp steve.schnepp@pwkf.org --- I finally fixed it.
On buildings & jungle there's DrawPrimitive() calls with a bigger number of vertices (5 or 6 and up to 8).
So the code flushed the buffer needlessly.
Once I rewrote the whole buffering code to code with any number of vertices, the slowdowns are fully gone.
https://bugs.winehq.org/show_bug.cgi?id=33814
--- Comment #34 from Steve Schnepp steve.schnepp@pwkf.org --- A very simple reproducer is at https://gist.github.com/steveschnepp/251ce5f2c5c046c40b10c6666a9eb964
the Wine PR https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
And here is a port of the PR to a application-space ddraw.dll https://github.com/steveschnepp/d3d7batch
That port does solve the issue for me, but feels like a workaround.