Regression in wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation.
Hi,
after investigating reports for the game 'World in Conflict', I identified the following patch to cause the game graphics to freeze (ambient sounds are still played though):
---- ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit commit ba90a740beb9ce9a839cc843db8d87f5a37becdd Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Sun Feb 10 22:20:15 2008 +0100
wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation.
This makes the code easier to read and the pieces borrowed from read_from_framebuffer are more correct than the code in LoadLocation.
:040000 040000 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf 3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls ----
The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as it lets the game properly detect the graphics card and thus enables additional graphics options (highend shaders, high-res textures, etc.). Apparently the freeze is only triggered with these options active.
The game uses events in its drawing code and ("always") hangs after the following output: fixme:d3d9:D3DPERF_BeginEvent (color 0xffffffff, name L"Update verlet cloth") : stub fixme:d3d9:D3DPERF_EndEvent (void) : stub
At one point, it was followed by this error: err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo has SFLAG_INSYSMEM set!
The point of the freeze appears to depend on many factors. If I move the camera around, it appears to freeze earlier than just letting the game run (e.g. a replay of a match). But once the patch is excluded, the game no longer freezes.
If more info is needed, please specify how I can obtain it.
On Friday 23 May 2008, Markus wrote:
Hi,
after investigating reports for the game 'World in Conflict', I identified the following patch to cause the game graphics to freeze (ambient sounds are still played though):
ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit commit ba90a740beb9ce9a839cc843db8d87f5a37becdd Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Sun Feb 10 22:20:15 2008 +0100
wined3d: Add read_from_framebuffer_texture which combines code fromread_from_framebuffer (drawpixels) and LoadLocation.
This makes the code easier to read and the pieces borrowed from read_from_framebuffer are more correct than the code in LoadLocation.:040000 040000 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf
3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls
The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as it lets the game properly detect the graphics card and thus enables additional graphics options (highend shaders, high-res textures, etc.). Apparently the freeze is only triggered with these options active.
The game uses events in its drawing code and ("always") hangs after the following output: fixme:d3d9:D3DPERF_BeginEvent (color 0xffffffff, name L"Update verlet cloth") : stub fixme:d3d9:D3DPERF_EndEvent (void) : stub
At one point, it was followed by this error: err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo has SFLAG_INSYSMEM set!
The point of the freeze appears to depend on many factors. If I move the camera around, it appears to freeze earlier than just letting the game run (e.g. a replay of a match). But once the patch is excluded, the game no longer freezes.
If more info is needed, please specify how I can obtain it.
Could you file a bug with the above information? Otherwise it's likely to get lost/forgotten.
- Neil
Neil Skrypuch wrote:
On Friday 23 May 2008, Markus wrote:
Hi,
after investigating reports for the game 'World in Conflict', I identified the following patch to cause the game graphics to freeze (ambient sounds are still played though):
ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit commit ba90a740beb9ce9a839cc843db8d87f5a37becdd Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Sun Feb 10 22:20:15 2008 +0100
wined3d: Add read_from_framebuffer_texture which combines code fromread_from_framebuffer (drawpixels) and LoadLocation.
This makes the code easier to read and the pieces borrowed from read_from_framebuffer are more correct than the code in LoadLocation.:040000 040000 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf
3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls
The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as it lets the game properly detect the graphics card and thus enables additional graphics options (highend shaders, high-res textures, etc.). Apparently the freeze is only triggered with these options active.
The game uses events in its drawing code and ("always") hangs after the following output: fixme:d3d9:D3DPERF_BeginEvent (color 0xffffffff, name L"Update verlet cloth") : stub fixme:d3d9:D3DPERF_EndEvent (void) : stub
At one point, it was followed by this error: err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo has SFLAG_INSYSMEM set!
The point of the freeze appears to depend on many factors. If I move the camera around, it appears to freeze earlier than just letting the game run (e.g. a replay of a match). But once the patch is excluded, the game no longer freezes.
If more info is needed, please specify how I can obtain it.
Could you file a bug with the above information? Otherwise it's likely to get lost/forgotten.
- Neil
Please have a look at this bugs here before you file another one. Probably your problem is already reported.
http://bugs.winehq.org/show_bug.cgi?id=11584 http://bugs.winehq.org/show_bug.cgi?id=12550
There are a couple of bugs referred to this patch.
Cheers Rico
-
Markus -
Neil Skrypuch -
Rico Schüller