http://bugs.winehq.org/show_bug.cgi?id=35032
Bug #: 35032 Summary: starcraft unbearably slow in fullscreen mode Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: j.schauer@email.de Classification: Unclassified Regression SHA1: 94ae743ea668e49d40ae4e2dc5fe1f5d9be018cb
Created attachment 46698 --> http://bugs.winehq.org/attachment.cgi?id=46698 glxinfo
Hi,
while Starcraft (specifically Broodwar) worked perfectly before, I now observed that whenever I would let it run in fullscreen mode, it would be horribly slow (about 2-3 fps) so that even moving the mouse cursor would become a frustrating task. This issue does not show when starcraft is not drawing fullscreen, for example when it is in a virtual desktop or when my window manager (awesome) constricts it to a window.
This might be a problem with my graphics card/driver but since it worked fine in wine a few years ago, I ran a regression test and found out that the problem was introduced with commit 94ae743 which changed the DefaultSurfaceType to opengl.
On my host I'm running Debian jessie (testing) amd64 with mesa 9.1 and intel 2.19 drivers. I did all the regression testing in a chroot environment with Debian squeeze i386 because the specific wine versions around commit 94ae743 would not compile when libxml2 was too new.
I only have access to Intel graphics hardware, so I can't test on a machine with a different graphics card. The laptop I was testing on was a Dell E6510 with Ironlake graphics as you can see in the attached glxinfo output.
I was told in IRC that this problem is likely a driver issue but nevertheless I would like to know whether there is a patch that I can apply to my specific wine version to restore the functionality I had before commit 94ae743 was applied?
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #1 from josch j.schauer@email.de 2013-12-02 04:33:24 CST --- Hi,
I was being made aware of bug#34547. The reporter claims that for him wine-1.5.28 worked flawlessly which is not the case for me.
Nevertheless, I also got the warn:d3d_perf:wined3d_surface_blt messages but only when running starcraft in fullscreen mode. Once my window manager constricts it to something that is not the fullscreen the messages go away and the game is faster.
I also tried the patch attached to bug#34547 with the current git HEAD. While I can confirm that the warn:d3d_perf:wined3d_surface_blt messages go away in fullscreen mode with this patch, I do not see any difference in performance on my system. Starcraft is still unplayably slow (no visible difference in speed) during fullscreen mode and faster when not fullscreen.
http://bugs.winehq.org/show_bug.cgi?id=35032
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #2 from josch j.schauer@email.de 2013-12-03 12:44:49 CST --- I compiled the most recent mesa version from git as of now: 5b331f6fcbf226f18e0c517ffdce30a39bb92982 from 2013-11-23 which was released after mesa 10.0.
It did not make any difference in the effect I observed.
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #3 from josch j.schauer@email.de 2013-12-03 13:39:28 CST --- I now recompiled mesa with -DDEBUG to get some output with INTEL_DEBUG=perf and here it is: intel_debug_perf.log
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #4 from josch j.schauer@email.de 2013-12-03 13:40:02 CST --- Created attachment 46718 --> http://bugs.winehq.org/attachment.cgi?id=46718 intel_debug_perf.log
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #5 from josch j.schauer@email.de 2013-12-05 12:41:25 CST --- Following some suggestions from http://dri.freedesktop.org/wiki/IntelPerformanceTuning/ yielded:
When the game is windowed (virtual desktop or otherwise) and running smoothly then CPU is used 80% and GPU around 80%. When the game is fullscreen and running slow and choppy then CPU is used 40% and GPU is 100%.
This suggests that the bottleneck during fullscreen mode is the GPU.
I'm unable to execute "perf record -g -e i915:i915_gem_request_wait_begin" for a more detailed analysis because it returns: invalid or unsupported event: 'i915:i915_gem_request_wait_begin
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #6 from josch j.schauer@email.de 2013-12-06 17:25:26 CST --- Created attachment 46764 --> http://bugs.winehq.org/attachment.cgi?id=46764 gdi fix
This patch does not fix the issue I have with starcraft and the opengl renderer (this still persists) but with this patch I can now play starcraft with the gdi renderer without problems (since commit 6325f3dd the window was black only).
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com 2013-12-06 19:51:39 CST --- Thank you very much for the patch, I'm finally able to play StarCraft in my intel graphics board now.
http://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #8 from josch j.schauer@email.de 2013-12-07 01:42:11 CST --- Bruno: sorry, forgot to mention: the patch is by Henri Verbeet so all thanks goes to him for fixing this that quickly :)
For further reproducibility of this bug with the opengl renderer on intel graphics cards I also just tried the starcraft demo from http://ftp.blizzard.com/pub/starcraft/demos/SCDemo.exe (great times when demos were 29M).
I can confirm that this bug does not only affect the full version of the game but also the demo. At least on my intel system and with the opengl renderer. With Henri Verbeets fix, it works perfectly with gdi.
http://bugs.winehq.org/show_bug.cgi?id=35032
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM
--- Comment #9 from Henri Verbeet hverbeet@gmail.com --- The issue with the GDI ddraw renderer should be fixed by commits 38495706b79bc77759aca918ba60d9d226b072ee and 544e52bff40dd51a3f4f9954a6a32a75ff70ae07. As far as I can tell the issue with the OpenGL renderer is in the Intel driver, so I'm resolving this UPSTREAM. You should probably file a bug for that at bugs.freedesktop.org if you haven't already, and if you like you can CC me on that.
http://bugs.winehq.org/show_bug.cgi?id=35032
programmer11180@programist.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |programmer11180@programist. | |ru
https://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Henri Verbeet from comment #9)
The issue with the GDI ddraw renderer should be fixed by commits 38495706b79bc77759aca918ba60d9d226b072ee and 544e52bff40dd51a3f4f9954a6a32a75ff70ae07. As far as I can tell the issue with the OpenGL renderer is in the Intel driver, so I'm resolving this UPSTREAM. You should probably file a bug for that at bugs.freedesktop.org if you haven't already, and if you like you can CC me on that.
Henri, can you give hints about what to write in the freedesktop report? I just tested this and it's still an issue.
https://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #11 from Henri Verbeet hverbeet@gmail.com --- (In reply to Bruno Jesus from comment #10)
Henri, can you give hints about what to write in the freedesktop report? I just tested this and it's still an issue.
At this point, mostly just the usual things about how to reproduce it, like hardware and software versions, etc., and perhaps a link to this bug report. It would of course also be helpful if you could already do some profiling on your own like e.g. the earlier mentioned http://dri.freedesktop.org/wiki/IntelPerformanceTuning/, but what tends to make profiling hard is that it's not always obvious how to interpret the results.
https://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #12 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 50976 --> https://bugs.winehq.org/attachment.cgi?id=50976 intel_gpu_top while running StarCraft
The attached screenshot shows what happens when running StarCraft in intel_gpu_top. The screenshot was taken using a second screen while the first screen was fullscreen inside the game.
The screenshot shows that all the time is spent in CS, which I guess is related to "critical section" or "command stream"? I'm trying to understand the results...
https://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 50977 --> https://bugs.winehq.org/attachment.cgi?id=50977 intel_gpu_top while running StarCraft in Virtual Desktop
This is just for comparison, when playing in virtual desktop the games runs fine.
https://bugs.winehq.org/show_bug.cgi?id=35032
--- Comment #14 from Henri Verbeet hverbeet@gmail.com --- (In reply to Bruno Jesus from comment #12)
The screenshot shows that all the time is spent in CS, which I guess is related to "critical section" or "command stream"? I'm trying to understand the results...
My guess would be the command stream unit as in section 3.2.2 of http://www.x.org/docs/intel/965/VOL_1_graphics_core.pdf, but that doesn't necessarily make it more obvious what's going on.
https://bugs.winehq.org/show_bug.cgi?id=35032
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vladfi2@gmail.com
--- Comment #15 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 36831 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=35032
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=35032
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #17 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.