Bug 21653 - Can't start Enemy Territory on RV350
Summary: Can't start Enemy Territory on RV350
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL: http://www.phoronix.com/forums/showth...
Whiteboard:
Keywords:
: 21936 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-10 02:45 UTC by Pieter Agten
Modified: 2009-07-09 00:29 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Console output (2.88 KB, text/plain)
2009-05-10 02:45 UTC, Pieter Agten
no flags Details
xorg config file (3.49 KB, text/plain)
2009-05-10 02:46 UTC, Pieter Agten
no flags Details
xorg log file (33.15 KB, text/plain)
2009-05-10 02:46 UTC, Pieter Agten
no flags Details
Don't expose fbconfigs without stencil if stencil is accelerated (812 bytes, patch)
2009-05-11 02:25 UTC, Michel Dänzer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pieter Agten 2009-05-10 02:45:59 UTC
Created attachment 25686 [details]
Console output

When trying to run the game Enemy Territory on my system, my display resolution changes to 800x600, I get a number of X error messages and finally a segmentation fault.

I'm running Arch Linux with kernel version 2.6.29, X Server 1.6.1 and ATI driver version 6.12.2. My video card is an RV350 (Mobility Radeon 9600 M10).

I do think this game should run on my system because it has 'Platinum' status on the RadeonProgram page (http://www.x.org/wiki/RadeonProgram).

I have a thread on the phoronix forum about this problem. Someone has mentioned that downgrading to xserver 1.5.3 solves this issue. (see http://www.phoronix.com/forums/showthread.php?t=16525).

The console output from when I start the game is attached, as well as my xorg.conf and Xorg log.

I have tried to use XAA instead of EXA but that doesn't make a difference. I'm not running Compiz or other compositing manager.
Comment 1 Pieter Agten 2009-05-10 02:46:33 UTC
Created attachment 25687 [details]
xorg config file
Comment 2 Pieter Agten 2009-05-10 02:46:55 UTC
Created attachment 25688 [details]
xorg log file
Comment 3 Michel Dänzer 2009-05-11 02:25:25 UTC
Created attachment 25726 [details] [review]
Don't expose fbconfigs without stencil if stencil is accelerated

Does this Mesa patch help?
Comment 4 Juan M. Méndez 2009-05-11 17:47:19 UTC
Same problem here. I can confirm that downgrading the xserver fixed the issue for Enemy Territory with the reported errors.

Other OpenGL apps were very slow in the new version.
My card is an ATI Technologies Inc RV280 [Radeon 9200 PRO]
Comment 5 Pieter Agten 2009-05-13 02:51:37 UTC
I modified the 'Don't expose fbconfigs without stencil if stencil is accelerated' patch a little to work on the stable 7.4.1 Mesa branch and applied it. Unfortunately it didn't change anything, I still get the same behaviour and console output when trying to start the game.

I'll try to compile and install the Mesa 7.5 development branch with the same patch and see if that makes a difference.
Comment 6 Pieter Agten 2009-05-13 03:27:53 UTC
Same problem with version 7.5-rc1.

However I might be doing something wrong with compiling/installing it because glxinfo | grep version still indicates: 'OpenGL version string: 1.3 Mesa 7.4.1'. I think this should be 'Mesa 7.5'? Do I need to do anything special after compiling and installing the new Mesa library in order to use it?
Comment 7 Michel Dänzer 2009-05-13 06:23:33 UTC
(In reply to comment #6)
> However I might be doing something wrong with compiling/installing it because
> glxinfo | grep version still indicates: 'OpenGL version string: 1.3 Mesa
> 7.4.1'. I think this should be 'Mesa 7.5'?

Sounds like maybe you're using indirect rendering, try setting LIBGL_DEBUG=verbose to get more information.

Note that for the patch to take effect you also need to restart the X server and verify with

grep _dri /var/log/Xorg.0.log

that it's loading the patched r300_dri.so. Guess I should have mentioned this before.
Comment 8 Pieter Agten 2009-05-23 08:08:26 UTC
Alright. Sorry for the long delay, I've been very busy.

I just recompiled the r300 driver with the patch and it did fix it! The game works very well now. I also compiled the Mesa sources from git without the patch, to make sure it wasn't just the newer Mesa code that fixed it, but without the patch it doesn't work. So thank you very much Michel!

I'm not really sure what to do with this bug. Should I mark it as resolved? Will this patch make it into the code for Mesa 7.5?
Comment 9 Mario Limonciello 2009-05-23 08:18:15 UTC
I will be out of the office from Monday May 25th through Wednesday June 3rd for a conference in Spain.  I will still be checking and responding to email, but keep in mind my time zone when expecting a response.

For any time sensitive Linux issues, please contact Amit Bhutani.
For any critical FI related issues, please contact Veronica Camp.
Comment 10 Michel Dänzer 2009-06-04 02:21:32 UTC
(In reply to comment #8)
> 
> I'm not really sure what to do with this bug. Should I mark it as resolved?

No, that's only done once the fix lands in Git.

> Will this patch make it into the code for Mesa 7.5?

Not sure yet. It's really just a workaround and may not help in all cases, e.g. when running X at depth 16. It would probably be better to fix the xserver GLX code to mark the 32 bit ARGB visual as non-conformant again without DRI2.
Comment 11 Sunil Mekathotti 2009-06-05 05:21:54 UTC
The patch attached in this bug also fixed my problem in bug #21936 
Comment 12 Alex Deucher 2009-06-05 07:42:55 UTC
*** Bug 21936 has been marked as a duplicate of this bug. ***
Comment 13 Michel Dänzer 2009-07-09 00:29:03 UTC
Better fix pushed to Git master / mesa_7_5_branch as 25b492b976632269dfa3de164545d50a53c090ce and cherry-picked to mesa_7_4_branch as a3537de1ddc834c2e6efc05bca4d1e4b1a51242e .


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.