[Bug 31014] New: Performance regression: Audiosurf unplayable in wine 1.5.7

http://bugs.winehq.org/show_bug.cgi?id=31014

Bug #: 31014
           Summary: Performance regression: Audiosurf unplayable in wine
                    1.5.7
           Product: Wine
           Version: 1.5.7
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]
    Classification: Unclassified
   Regression SHA1: 70008999486651b62bef641196a31f6c7002d0e5

Up to wine 1.5.6, the game Audiosurf [1] worked fine on my system (Debian
testing amd64, Linux 3.2, AMD Radeon HD 3200, fglrx 12-4, wine compiled
myself). However, after updating to version 1.5.7, the game is rendered
unplayable: The menus are still fine, but the actual game runs with less than 5
fps. Sound is still as expected, but of course that's of no help.

I did a bisect with the following result:

70008999486651b62bef641196a31f6c7002d0e5 is the first bad commit
commit 70008999486651b62bef641196a31f6c7002d0e5
Author: Henri Verbeet 
Date:   Fri Jun 22 15:57:28 2012 +0200

wined3d: Just forward wined3d_device_get_display_mode() to the appropriate
swapchain.

:040000 040000 901aae9a1f10635dc27916a9c9260710657e4516
5e0f894018153ba040091ace29474ccd9cfd0288 M      dlls

I hope I added the correct person to CC - the email address from the commit
does not have an account here, so I googled around a bit to find out which
email address the author uses in bugzilla.

Please let me know if there is any other debugging I could do.

[1] http://www.audio-surf.com/ (free demo available)

[Bug 31014] Audiosurf is to slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |performance, regression
            Summary|Performance regression:     |Audiosurf is to slow to be
                   |Audiosurf unplayable in     |playable
                   |wine 1.5.7                  |

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

Ralf Jung  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Audiosurf is to slow to be  |Audiosurf is too slow to be
                   |playable                    |playable

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

--- Comment #1 from Ralf Jung  2012-06-29 15:39:54 CDT ---
I did some more analysis on this:

Audiosurf calls wined3d_device_get_display_mode with a swapchain_idx of 0. In
current wine, this means that the returned hr will be uninitialized, and the
mode structure left unchanged - so there's garbage in there (I added a FIXME to
get these values):

fixme:d3d:wined3d_device_get_display_mode device 0x146a80, swapchain_idx 0,
mode 0xda80ac, rotation (nil).
fixme:d3d:wined3d_device_get_display_mode hr 4, Return width 14348384, height
14348216, format_id 98596972, refresh_rate -2147467259

Interesting enough, just removing the if (so that swapchain 0 is properly
queried) does not fix the issue even though the data looks much saner:

fixme:d3d:wined3d_device_get_display_mode device 0x146a80, swapchain_idx 0,
mode 0xda80ac, rotation (nil).
fixme:d3d:wined3d_device_get_display_mode hr 0, Return width 1366, height 768,
format_id 115, refresh_rate 60

I am still experimenting to come up with a minimal patch fixing/working around
the issue locally.

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

--- Comment #2 from Henri Verbeet  2012-06-30 04:13:57 CDT ---
(In reply to comment #1)
> I did some more analysis on this:
>
> Audiosurf calls wined3d_device_get_display_mode with a swapchain_idx of 0. In
> current wine, this means that the returned hr will be uninitialized, and the
> mode structure left unchanged - so there's garbage in there (I added a FIXME to
> get these values):

That doesn't sound right, what version of Wine are you using / what does your
wined3d_device_get_display_mode() actually look like?
> I am still experimenting to come up with a minimal patch fixing/working around
> the issue locally.
> From the description, this sounds like some variant of bug 30184, does

http://bugs.winehq.org/attachment.cgi?id=40780 make it any better?

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

--- Comment #3 from Ralf Jung  2012-06-30 04:36:45 CDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > I did some more analysis on this:
> >
> > Audiosurf calls wined3d_device_get_display_mode with a swapchain_idx of 0. In
> > current wine, this means that the returned hr will be uninitialized, and the
> > mode structure left unchanged - so there's garbage in there (I added a FIXME to
> > get these values):
>
> That doesn't sound right, what version of Wine are you using / what does your
> wined3d_device_get_display_mode() actually look like?

I am sorry, this was an artefact created by reverting only parts of the
patches.

I will attach a patch that fixes the issue here. The difference in the return
value (compared to current origin/master) is that refresh_rate and
scanline_ordering are set to 0 - that is, however, not the problem. Even
forcing those to be 0 after calling wined3d_swapchain_get_display_mode does not
make it work.

What confused me during debugging is that the device-specific display mode
function calls the swapchain-specific one, which however uses only the device
pointer to call the adapter-specific function. But then, I don't know the API
;-)

I noticed during my debugging and logging that the function in question is
called *very* often - more than 700 times in my short logfile. Could it be that
always calling EnumDisplaySettingsExW is just so much slower than using the
data from the device?
> From the description, this sounds like some variant of bug 30184, does
> http://bugs.winehq.org/attachment.cgi?id=40780 make it any better?

I will try it and let you know.

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

--- Comment #4 from Ralf Jung  2012-06-30 04:52:53 CDT ---
Created attachment 40800
  --> http://bugs.winehq.org/attachment.cgi?id=40800
A patch fixing/working around the issue described here

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

Ralf Jung  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #5 from Ralf Jung  2012-06-30 05:09:01 CDT ---
The xrandr patch also fixes the issue, so yes - it is a duplicate. Good catch,
thanks :)

*** This bug has been marked as a duplicate of bug 30184 ***

[Bug 31014] Audiosurf is too slow to be playable

http://bugs.winehq.org/show_bug.cgi?id=31014

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Jerome Leclanche  2012-07-19 07:43:54 CDT ---
Closing