The bug was already described in http://bugs.winehq.org/show_bug.cgi?id=18232 To reiterate: touhou 6-10 run fine in wine at full speed, but touhou 11/12 run very slow hogging X (80-90% for me in top). The hardware requirements for the games are very low so it shouldn't happen. system: archlinux 64bit 32bit wine 1.1.33 kernel 2.6.31.6 radeon X1550 mesa 7.6 xf86-video-ati 6.12.99.git20091014 As I don't know how to delve deeper into X I can't find out what is actually happening. But because it's a 3d 'heavy' game I fill the bugreport for now against mesa/radeon.
Created attachment 31341 [details] short xorg session with touhou 11 running I compiled xorg-server-1.7.1.901 with -pg and ran a short session with touhou 11. Note: I didn't recompile any other libraries which link against the Xorg executable. If anybody could enlighten me if I need to do so and what (or say to just drop it) it would be helpful. Some more information about the bug: - the program shows an animated loading screen at startup - the program runs for 1-2 seconds at full speed, then suddenly the framerate drops - during that time nothing visible changes (still at the loading screen, same animations, same sprites)
ok, got oprofile running and it shows me: $ oprofile | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 1196504 73.1266 r300_dri.so 113025 6.9077 vmlinux 52682 3.2198 libSAD.so.2.0.0 48921 2.9899 libdricore.so 28411 1.7364 libc-2.11.so
better results: $ opreport -l /usr/lib/xorg/modules/dri/r300_dri.so | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 samples % symbol name 633992 98.0560 radeon_ptr_4byte 11532 1.7836 radeonReadRGBASpan_ARGB8888 85 0.0131 radeon_get_cliprects 75 0.0116 radeonEmitState 63 0.0097 radeonWriteRGBASpan_ARGB8888 52 0.0080 r300DrawPrims 27 0.0042 r500SetupRSUnit $ opreport | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 646564 71.7840 r300_dri.so 68319 7.5850 vmlinux 36815 4.0873 libSAD.so.2.0.0 27617 3.0661 libdricore.so 14973 1.6624 libc-2.11.so hope that helps
(In reply to comment #3) > samples % symbol name > 633992 98.0560 radeon_ptr_4byte > 11532 1.7836 radeonReadRGBASpan_ARGB8888 This is a software fallback - my bet would be for CopyTex[Sub]Image2d, which the driver currently doesn't accelerate. I thought there was some branch somewhere implementing that already, but can't remember where this was...
(In reply to comment #4) > (In reply to comment #3) > > samples % symbol name > > 633992 98.0560 radeon_ptr_4byte > > 11532 1.7836 radeonReadRGBASpan_ARGB8888 > > This is a software fallback - my bet would be for CopyTex[Sub]Image2d, which > the driver currently doesn't accelerate. I thought there was some branch > somewhere implementing that already, but can't remember where this was... > did you mean https://bugs.freedesktop.org/show_bug.cgi?id=19366 ?
Please try my r300-blit branch.
(In reply to comment #6) > Please try my r300-blit branch. Was half success, failed half. My problem is that I can only get indirect rendering working and cannot compile 32bit libdrm/mesa, so wine uses older 32bit versions of mesa and drm (no r300_dri.so exists for 32bit so it is consistent with older tests before the upgrade which used indirect rendering, too). This is a problem specific to my distribution. Good side: the game runs much faster now (40-50fps). Downside: All menus and the loading screen look good, but ingame I get garbled output (like you see with old crts when the resolution is set too high). Funny is that the ingame menus are drawn properly over the garbled ingame rendering. I can't tell if this is because of the version difference between the 32bit and 64bit libraries or a real bug.
Created attachment 31351 [details] ingame garbled
I have problems using the r300-blit branch too. When I start the game an assertion in r300_texcopy.c fails: r300_texcopy.c:144: r300CopyTexSubImage2D: Assertion `target == 0x0DE1' failed. which is "target == GL_TEXTURE_2D" in the source. After that the game crashes. Am I doing something wrong? Versions should be the same as Allen's but i have a radeon 9550.
(In reply to comment #9) > I have problems using the r300-blit branch too. > > When I start the game an assertion in r300_texcopy.c fails: > > r300_texcopy.c:144: r300CopyTexSubImage2D: Assertion `target == 0x0DE1' failed. > > which is "target == GL_TEXTURE_2D" in the source. After that the game crashes. > > Am I doing something wrong? > > Versions should be the same as Allen's but i have a radeon 9550. > It seems you have an old version of the branch. This assertion has been removed. Try pulling latest changes.
In the new version, the assertion is gone but it still crashes. $ wine th11.exe [...] drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. $ dmesg | tail -n2 [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
Created attachment 31415 [details] Full output of wine before the crash.
Apparently the r300-blit branch only works on KMS without libtxc_dxtn.so, or else it crashes with: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. With KMS + libtxc_dxtn.so dmesg also shows: [ 170.756561] [drm:r300_packet0_check] *ERROR* Invalid texture format 16 [ 170.756566] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Without KMS dmesg shows: [ 154.902575] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1) [ 154.902581] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
(In reply to comment #13) > Apparently the r300-blit branch only works on KMS without libtxc_dxtn.so, or > else it crashes with: > drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See > dmesg for more info. > > With KMS + libtxc_dxtn.so dmesg also shows: > [ 170.756561] [drm:r300_packet0_check] *ERROR* Invalid texture format 16 > [ 170.756566] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > > Without KMS dmesg shows: > [ 154.902575] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed > range check (reg=4540 sz=1) > [ 154.902581] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed > Ah, right. I forgot you need to hack the radeon drm module to fix the texture size calculation for compressed formats (KMS case). I didn't check it under the UMS mode, but I hope to do it this week.
Please apply this patch http://pastebin.ca/1688366 to mesa and provide me with the full app output. Set RADEON_DEBUG=cs env var for the app.
Created attachment 31503 [details] prey debug output Console output of prey game run with RADEON_DEBUG=cs after compiling current r300-blit branch with the patch on comment #15 without libtxc_dxtn.so under UMS. dmesg also shows: [ 5119.936101] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1) [ 5119.936106] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
(In reply to comment #16) > Created an attachment (id=31503) [details] > prey debug output > > Console output of prey game run with RADEON_DEBUG=cs after compiling current > r300-blit branch with the patch on comment #15 without libtxc_dxtn.so under > UMS. > dmesg also shows: > [ 5119.936101] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed > range check (reg=4540 sz=1) > [ 5119.936106] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed > Hmm, something's wrong - no cs is printed on the exit (and that's what the patch I've asked you to apply does). Do you have libdrm_radeon installed? Lukas: Please create the same log.
Created attachment 31510 [details] openarena console output > Hmm, something's wrong - no cs is printed on the exit (and that's what the > patch I've asked you to apply does). I am sure I applied it. > Do you have libdrm_radeon installed? Yes: checking for LIBDRM_RADEON... yes Also attaching openarena output where I notice also: Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x0)
(In reply to comment #18) > Created an attachment (id=31510) [details] > openarena console output > > > Hmm, something's wrong - no cs is printed on the exit (and that's what the > > patch I've asked you to apply does). > > I am sure I applied it. > > > Do you have libdrm_radeon installed? > > Yes: > checking for LIBDRM_RADEON... yes > > Also attaching openarena output where I notice also: > Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x0) > Darn. Looks like cs printing isn't implemented for UMS. I'll try reproducing the bug locally.
(In reply to comment #19) > (In reply to comment #18) > > Created an attachment (id=31510) [details] [details] > > openarena console output > > > > > Hmm, something's wrong - no cs is printed on the exit (and that's what the > > > patch I've asked you to apply does). > > > > I am sure I applied it. > > > > > Do you have libdrm_radeon installed? > > > > Yes: > > checking for LIBDRM_RADEON... yes > > > > Also attaching openarena output where I notice also: > > Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x0) > > > > Darn. Looks like cs printing isn't implemented for UMS. > > I'll try reproducing the bug locally. > The problem seems to be UMS specific, so please use KMS for now.
The r300-blit branch is now merged in mesa master (7.8-dev), however it's currently enabled only without KMS.
> The r300-blit branch is now merged in mesa master (7.8-dev), however it's > currently enabled only without KMS. Sorry, only *with* KMS
(In reply to comment #22) > > The r300-blit branch is now merged in mesa master (7.8-dev), however it's > > currently enabled only without KMS. > > Sorry, only *with* KMS > Thank you. I finally got around trying it out. Tried it out with kernel 2.6.33-rc3 and libdrm/mesa/xf86-video-ati from yesterday. The game now runs at full speed but the ingame graphic isn't visible (all black). Before, it was garbled with KMS enabled (see old screenshot for this bugreport) so I think it has something to do with 32bit libs compiled for the old API and indirect rendering which uses the 64bit libraries with the new API. But I don't know yet if I can recompile the 32bit libraries without introducing errors to check my theory so I will leave it at this for now. Thank you for your great work.
(In reply to comment #23) > (In reply to comment #22) > But I don't know yet if I can recompile the 32bit libraries without introducing > errors to check my theory so I will leave it at this for now. I meant 'recompile at all'. Archlinux isn't multilib and misses lots of necessary libraries for 32bit on 64bit (udev?).
I finally got KMS working with thursday's mesa and xf86-video-ati having the same issue: game runs at full speed with OffscreenRenderingMode=backbuffer but only the menus are drawn. With OffscreenRenderingMode=fbo ingame is visible but the game is still slow (~20fps) like in the bug at winehq, which seems to be not radeon specific. I use 32bit only so I think Allen's theory is disproved.
(In reply to comment #25) > I finally got KMS working with thursday's mesa and xf86-video-ati having the > same issue: game runs at full speed with OffscreenRenderingMode=backbuffer but > only the menus are drawn. > > With OffscreenRenderingMode=fbo ingame is visible but the game is still slow > (~20fps) like in the bug at winehq, which seems to be not radeon specific. > > I use 32bit only so I think Allen's theory is disproved. > I have to admit I didn't play around with OffscreenRenderingMode, but doing it now, I get the opposite from your results. 'fbo' results in black ingame, 'backbuffer' results in slow (~30fps) but playable game. I didn't update mesa/ati/drm since my last message in this thread. Kernel went up to 2.6.33-rc7.
(In reply to comment #26) > (In reply to comment #25) > > I finally got KMS working with thursday's mesa and xf86-video-ati having the > > same issue: game runs at full speed with OffscreenRenderingMode=backbuffer but > > only the menus are drawn. > > > > With OffscreenRenderingMode=fbo ingame is visible but the game is still slow > > (~20fps) like in the bug at winehq, which seems to be not radeon specific. > > > > I use 32bit only so I think Allen's theory is disproved. > > > > I have to admit I didn't play around with OffscreenRenderingMode, but doing it > now, I get the opposite from your results. 'fbo' results in black ingame, > 'backbuffer' results in slow (~30fps) but playable game. > > I didn't update mesa/ati/drm since my last message in this thread. Kernel went > up to 2.6.33-rc7. > Scratch that, I tried with a new build and got the same problems as Lukas, except my fps is much worse. The old build was using git from january (99637ba80e376e8dcdce8fb1597f55256c461aee) and worked described as above. The new one is from today (edd85bcd6bc92beaf266a602da76d2aefe836a8e). The build options are the same and I updated libdrm and xf86-video-ati with it, so something changed during that time.
Today I updated mesa/libdrm/xf86-video-ati again. Black ingame issue is gone, but game remains at playable but slow 30fps while menus have full speed.
I'm seeing this bug on my machine too and have been for over a year. Intel i945gm Mesa 7.8.1 Xserver 1.8.2 Linux 2.6.35 rc3 Touhou 11 and 12 are pretty much unplayable. 10 fps in fbo mode. 30 fps in-game (60 fps menu) in backbuffer and pbuffer modes. Touhou 10 has it's problem spots during complex scenes, but works fine. All of the older games are fine 90% of the time.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/273.
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.