Bug 25142 - touhou 11/12 run very slow in wine
Summary: touhou 11/12 run very slow in wine
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: 7.6
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-17 03:46 UTC by Allen Walker
Modified: 2019-09-18 18:39 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
short xorg session with touhou 11 running (77.03 KB, application/x-bzip)
2009-11-20 04:51 UTC, Allen Walker
Details
ingame garbled (512.09 KB, image/png)
2009-11-20 13:15 UTC, Allen Walker
Details
Full output of wine before the crash. (3.78 KB, text/plain)
2009-11-23 10:48 UTC, Lukas Weber
Details
prey debug output (12.38 KB, text/plain)
2009-11-27 01:37 UTC, Fabio Pedretti
Details
openarena console output (324.27 KB, text/plain)
2009-11-27 05:56 UTC, Fabio Pedretti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Allen Walker 2009-11-17 03:46:55 UTC
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.
Comment 1 Allen Walker 2009-11-20 04:51:46 UTC
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)
Comment 2 Allen Walker 2009-11-20 05:59:50 UTC
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
Comment 3 Allen Walker 2009-11-20 06:06:50 UTC
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
Comment 4 Roland Scheidegger 2009-11-20 06:51:38 UTC
(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...
Comment 5 Allen Walker 2009-11-20 07:10:40 UTC
(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 ?
Comment 6 Maciej Cencora 2009-11-20 08:06:21 UTC
Please try my r300-blit branch.
Comment 7 Allen Walker 2009-11-20 12:09:22 UTC
(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.
Comment 8 Allen Walker 2009-11-20 13:15:56 UTC
Created attachment 31351 [details]
ingame garbled
Comment 9 Lukas Weber 2009-11-22 11:38:37 UTC
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.
Comment 10 Maciej Cencora 2009-11-22 11:47:10 UTC
(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.
Comment 11 Lukas Weber 2009-11-23 10:46:22 UTC
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
Comment 12 Lukas Weber 2009-11-23 10:48:55 UTC
Created attachment 31415 [details]
Full output of wine before the crash.
Comment 13 Fabio Pedretti 2009-11-25 07:55:11 UTC
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
Comment 14 Maciej Cencora 2009-11-25 08:33:17 UTC
(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.
Comment 15 Maciej Cencora 2009-11-26 09:25:00 UTC
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.
Comment 16 Fabio Pedretti 2009-11-27 01:37:50 UTC
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
Comment 17 Maciej Cencora 2009-11-27 02:05:25 UTC
(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.
Comment 18 Fabio Pedretti 2009-11-27 05:56:02 UTC
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)
Comment 19 Maciej Cencora 2009-11-27 06:37:33 UTC
(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.
Comment 20 Maciej Cencora 2009-11-28 03:38:12 UTC
(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.

Comment 21 Fabio Pedretti 2009-12-22 02:48:00 UTC
The r300-blit branch is now merged in mesa master (7.8-dev), however it's currently enabled only without KMS.
Comment 22 Fabio Pedretti 2009-12-22 02:55:27 UTC
> 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
Comment 23 Allen Walker 2010-01-10 03:06:40 UTC
(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.
Comment 24 Allen Walker 2010-01-10 03:08:37 UTC
(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?).
Comment 25 Lukas Weber 2010-02-06 09:23:45 UTC
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.
Comment 26 Allen Walker 2010-02-07 15:11:47 UTC
(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.
Comment 27 Allen Walker 2010-02-22 15:16:22 UTC
(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.
Comment 28 Lukas Weber 2010-03-14 06:21:56 UTC
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.
Comment 29 Eric Appleman 2010-06-18 01:26:18 UTC
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.
Comment 30 GitLab Migration User 2019-09-18 18:39:55 UTC
-- 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.