When I try to run GTA2 in Wine, it runs so slow it's unplayable. On the same system Open Arena runs fine, so everything is set up well. GTA2 is pretty much playable in Wine even when using an 8 MB Savage chip, so it seems there are some bottlenecks in the graphics driver that cause this. The performance issues appear to come from missing support for certain OpenGL extensions that Wine uses. A list of these can be found here (line 47-144): http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/directx.c;h=478c21643ed7297a9b7342101086a06d892da5b9;hb=HEAD
GTA 2 can be downloaded for free from: http://www.rockstargames.com/classics/ While Wine 1.0.1 is the current stable version, the Wine developers heavily recommend to test against 1.1.13. Both Wine version experience this slowness.
Is there a way to adjust the graphics settings? My guess is that Wine exposes a different DX version for Savage and X4500HD. The higher version of DX enables shaders and a bunch of other things that may make it run much slower. The extension list in that file is, basically, a list of all the extensions that Wine might use to implement certain DX features. Is Wine complaining about the lack of any specific extension?
As far as I'm aware there is no such setting in Wine. This is the output Wine gives me: fixme:d3d:IWineD3DDeviceImpl_Release (0x134ef8) Device released with resources still bound, acceptable but unexpected fixme:d3d:dumpResources Leftover resource 0x135478 with type 1,WINED3DRTYPE_SURFACE fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface err:d3d:WineD3D_ChoosePixelFormat Can't find a suitable iPixelFormat fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(640,480) fixme:d3d:state_subpixel Render state WINED3DRS_SUBPIXEL not implemented yet I understand the problem not a missing extension, but an extension that's reported as available but is implemented in software.
Created attachment 22404 [details] sysprof profiling log After some chatting it seemed the slowness wasn't caused by an extension that would be implemented in software, but something else. I wasn't able to create a proper oprofile log yet, but here is a log created with sysprof which may be useful already.
confirmed on irc to be a distro packaging issue.
Yes, DRI wasn't working correctly, but I'm still not there yet, although this may not really be the appropriate bug anymore. I run the application now with the following variables set: LIBGL_DRIVERS_PATH=/usr/lib32/dri LIBGL_DEBUG=verbose At first this gave me an error that libdrm_intel.so.1 couldn't be found. It appeared there was only a 64-bit version installed and also no 32-bit version available from the repository, so I stole it from the i386 deb. Then I did two runs of the game and got these messages: run 1: libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0) libGL: OpenDriver: trying /usr/lib32/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib32/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 15, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 15, (OK) drmOpenByBusid: drmOpenMinor returns 15 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. fixme:win:EnumDisplayDevicesW ((null),0,0x33f6a4,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_Release (0x13a100) Device released with resources still bound, acceptable but unexpected fixme:d3d:dumpResources Leftover resource 0x137da8 with type 1,WINED3DRTYPE_SURFACE fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(640,480) err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 62 err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 63 err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64 fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x27923e8,0x2792b30): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x2792ba8,0x2792b30): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x2792398,0x2792b30): stub fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glDrawPixels @ surface.c / 1315 ../../../libdrm/intel/intel_bufmgr_gem.c:577: Error mapping buffer 637 (region): Cannot allocate memory . ../../../libdrm/intel/intel_bufmgr_gem.c:695: drm_intel_gem_bo_unmap: Assertion `bo_gem->virtual != ((void *)0)' failed. wine: Assertion failed at address 0xf7fa9430 (thread 0018), starting debugger... Can't attach process 0017: error 5 run 2: libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0) libGL: OpenDriver: trying /usr/lib32/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib32/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 15, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 15, (OK) drmOpenByBusid: drmOpenMinor returns 15 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. fixme:win:EnumDisplayDevicesW ((null),0,0x33f6a4,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_Release (0x13a100) Device released with resources still bound, acceptable but unexpected fixme:d3d:dumpResources Leftover resource 0x137da8 with type 1,WINED3DRTYPE_SURFACE fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/julius/.drirc: No such file or directory. fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(640,480) err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 62 err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 63 err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 64 fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x27923e8,0x2792b30): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x27923e8,0x2792b30): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x2792348,0x2792b30): stub fixme:d3d:state_subpixel Render state WINED3DRS_SUBPIXEL not implemented yet do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter.
There was an update to the 64-bit which somehow allowed me to run the game properly with DRI enabled. (I guess my versions weren't in sync at first.) With hardware DRI the performance problems are still there. In addition there is a strange colour covering the whole window (yellow or purple). It seems that even though the original problem wasn't the driver, the driver actually does have a performance problem. I'll make another sysprof log and will attach it.
Created attachment 22422 [details] sysprof profiling log with i965 driver
Created attachment 22552 [details] opreport on wined3d (from Wine version 1.1.13) I recompiled Wine with -g and was able to generate the annotated source. Here is all the source of wined3d. This should give more information about the cause of the performance problems.
Created attachment 22553 [details] the annotated source
The sysprof output doesn't have symbols for the 3d driver, and the oprofile output doesn't show anything outside of wined3d (where there's no cpu usage).
There was a problem which caused (with INTEL_DEBUG=fall) a lot of these messages to be printed: glDrawPixels() fallback: texturing enabled This was solved by installing mesa master. This also solved the strange colours in the game. The game is still running extremely slow, I will try to do more profiling tomorrow with this new mesa version.
Created attachment 22879 [details] opreport on the driver Here is the oprofile report of i965_dri with mesa master. It appears a software fallback is being triggered, but it's unclear what's exactly happening. A callgraph should be generated but this appears to be non-trivial.
Created attachment 23144 [details] callgraph of gta2 in Wine It seems I was able to create a more proper looking sysprof callgraph using a pure 32-bit environment. I've attached it. I hope this will provide more insight into the problem.
It appears the performance problem is related to the architecture of the driver and/or the hardware and can't be easily solved on that side other than the fixes that are currently in Mesa master. To let Wine work properly with the driver the registry key RenderTargetLockMode in the Wine registry needs to be set to readtex. This is also described here: http://wiki.winehq.org/UsefulRegistryKeys I will close the bug once the Mesa fixes are in a Mesa release and Wine is able to automaticly use this back-end.
It seems things are really improving with Mesa lately. It seems I'm running into a small regression though. I'm using the Mesa packages from the Ubuntu PPA, version 7.6.0~git20090706. GTA2 is again running slowly. I quickly made this profile with sysprof. Is Wine doing something bad here or could this be a driver regression? I will get proper versions of the driver & Wine with debug symbols compiled in if this profile is not clear enough. If there is a problem with Wine I'll approach the Wine developers about it. URL to sysprof output: http://haar.student.utwente.nl/~julius/gta2-20090709.sysprof
Here is a performance analysis made with perf (and kernel 2.6.31-rc2). It should provide more information: http://haar.student.utwente.nl/~julius/gta2-perf.data.gz
With the help of ickle on IRC, I now have a good callgraph. It can be found here: http://haar.student.utwente.nl/~julius/gta2.perfreport.gz
It turns out this problem is triggered by newer Wine versions which use the setting fbo instead of backbuffer for "RenderTargetLockMode". More information about this setting can also be found on this page: http://wiki.winehq.org/UsefulRegistryKeys The Wine developers say Intel's FBO implementation isn't right and this causes the slowness. Quoting what ickle wrote on IRC however: "internally there's no difference between framebuffers and backbuffers, so why it is screwing up is a mystery" The relevant code which take a lot of time in the callgraph is in these source files: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;h=83d02d4c29fde2fff5a27efea4b00d512096294f;hb=HEAD http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ddraw/surface.c;h=bde2234e9d24af4a6cdba1d5d4ee16e3f3261e5d;hb=HEAD
stringfellow> I think that comment is slightly misinformed in that that should probably read "OffscreenRenderingMode" instead of "RenderTargetLockMode" The sysprof data doesn't show fbo problems. Is your CPU 100% busy when things are overly slow right now?
The sysprof data is not accurate. stringfellow is indeed right, it should be OffscreenRenderingMode in my previous comment. The perf data shows the FBO performance problems. If there is a way I could provide more info, I'll try to do that. The game is also free (beer) nowadays, so I could also create a full package with Wine+GTA2 all set up for testing.
With RenderTargetLockMode set to readtex (why this isn't the default, I have no idea), the gta2 demo performs quite well, it seems. Is this the same for you?
OK, I'm going to go ahead and close this at this point. If you still have problems with this with current Mesa (particularly in 7.7 or master, which has improved readback performance), please reopen.
My apologies. I somehow missed the comment from October in my mailbox. The bug is indeed solved on the Intel side. The only problem left with the game is an input bug in the X11 server itself (on Ubuntu at least). As far as I know this is not specific to Intel. It's good the bug is closed now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.