http://bugs.winehq.org/show_bug.cgi?id=22303
Summary: Fallen Earth MMO : GL_APPLE_flush_buffer_range causes performance drop on OSX Product: Wine Version: 1.1.42 Platform: x86 URL: http://forums.fallenearth.com/fallenearth/showthread.p hp?t=35062 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: elanz1615@yahoo.com CC: stefan@codeweavers.com
This commit:
http://source.winehq.org/git/wine.git/?a=commit;h=a756caac0ca3dcd80019b56422...
Causes a performance drop in the Fallen Earth MMO under these conditions:
1. Macbook, Macbook Pro, IMac with ATI/NVIDIA, OSX 10.5.8 -> 10.6.3 2. Scaleform is rendering a swf element on the screen
OpenGl profiler shows that while scaleform is rendering a swf to the screen 65% of OpenGL is spent in MapBufferRange. As soon as the scaleform rendering is canceled performance returns to normal.
This is easy to reproduce in Fallen Earth which uses scaleform to render the help UI. When that UI is open fps is 10-12 when that UI is closed fps is 20-30.
Reverting that commit causes performance to remain constant when scaleform is rendering.
In Wine version 1.1.41 and 1.1.42 the performance drop is not quite as noticeable but it is still present and performance is still better without this commit.
http://bugs.winehq.org/show_bug.cgi?id=22303
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-07 15:11:56 --- Can you make a d3d+warn log and look for one of these message:
Cannot synchronize buffer lock due to a thread conflict wined3d_event_query_finish returned %u, dropping async buffer locks Failed to allocate event query memory, dropping async buffer locks Event queries not supported, dropping async buffer locks
I don't expect the 4h line to show up. In the 2nd one don't search for the line as-is. The %u will be replaced by a number, so search for "wined3d_event_query_finish returned" for example.
http://bugs.winehq.org/show_bug.cgi?id=22303
--- Comment #2 from Eric Lanz elanz1615@yahoo.com 2010-04-07 15:41:42 --- Created an attachment (id=27266) --> (http://bugs.winehq.org/attachment.cgi?id=27266) a section of the warn+d3d log from 1.1.42
Thank you for the response. I've attached a section of the terminal output after a run using WINEDEBUG=warn+d3d.
The statements in that log segment repeat every frame while a flash element is on screen, if there are no flash elements on screen then the log is empty.
http://bugs.winehq.org/show_bug.cgi?id=22303
--- Comment #3 from Stefan Dösinger stefandoesinger@gmx.at 2010-04-09 08:56:25 --- Apparently there's no complaint about dropping asynchronous buffer updates in this log. However, such a line would be printed only once for each affected buffer, so if you attached just the end of the terminal output it most likely won't be there. Please either grep the log yourself, or compress and attach a full log, not just the last part of it.
http://bugs.winehq.org/show_bug.cgi?id=22303
--- Comment #4 from Eric Lanz elanz1615@yahoo.com 2010-04-12 09:51:13 --- http://www.mediafire.com/file/nvmiwti5yyn/wineBug22303terminalOutput.txt.zip
The link above points to a 5mb zip containing the full 117 mb log file. In this run using the git tag 1.1.42 with no modifications the framerate during my test was:
With no swf elements on screen: ~50 fps
With a small 20x20 pixel question mark swf on screen: ~36 fps
I turned the swf on/off multiple times to try to capture as much output as I could.
At the top of the log is a glxinfo and system-profiler-mini output from my system in case you want to look at that.
I ran these grep commands on the file to check for the statements you mentioned:
Eric-Lanzs-MacBook-Pro:~ elanz1615$ grep -Hin "Cannot synchronize" ~/wineBug22303terminalOutput.txt Eric-Lanzs-MacBook-Pro:~ elanz1615$ grep -Hin "wined3d_event_query_finish" ~/wineBug22303terminalOutput.txt Eric-Lanzs-MacBook-Pro:~ elanz1615$ grep -Hin "Failed to allocate event" ~/wineBug22303terminalOutput.txt Eric-Lanzs-MacBook-Pro:~ elanz1615$ grep -Hin "Event queries not supported" ~/wineBug22303terminalOutput.txt
None were found, hopefully this will give you some idea of where I can look next.
http://bugs.winehq.org/show_bug.cgi?id=22303
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.6 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=22303
Stanisław Halik sthalik@misaki.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sthalik@misaki.pl
--- Comment #5 from Stanisław Halik sthalik@misaki.pl 2013-02-20 04:04:38 CST --- Please see:
http://ati.cchtml.com/show_bug.cgi?id=722
https://bugs.winehq.org/show_bug.cgi?id=22303
--- Comment #6 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over 700 days. Is this still an issue in current (1.7.36 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=22303
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=22303
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #7 from winetest@luukku.com ---
From bug 33318
I am not sure but this could have been fixed.
/* GL_ARB_map_buffer_range and GL_APPLE_flush_buffer_range provide the same * functionality. Prefer the ARB extension */ gl_info->supported[APPLE_FLUSH_BUFFER_RANGE] = FALSE;
To me it looks like that the extension isn't in use.
Some 3d guy would know better.
https://bugs.winehq.org/show_bug.cgi?id=22303
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #8 from Stefan Dösinger stefan@codeweavers.com --- These lines exist at least since 2012 according to git blame (where e834c920e moved them around), and if my memory serves me right I added them even earlier when I added GL_ARB_map_buffer_range support. It's just a precaution that we don't have both extensions enabled at the same time.
OSX only supports GL_ARB_map_buffer_range in core contexts, in legacy contexts we use GL_APPLE_flush_buffer_range. Wine uses legacy contexts unless you explicitly enabled core contexts (e.g. for d3d10/11) in the registry because some rarely used blit operations still rely on immediate mode draws.
https://bugs.winehq.org/show_bug.cgi?id=22303
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur vanilla with wine-7.10?