home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


ATI+Linux crash-on-exit fix and ATI *REALLY* hates Linux

by eihrul on 07/24/2007 09:22, 22 messages, last message: 08/06/2007 04:59, 6384 views, last view: 03/28/2024 18:13

First off, here's a patch for the crash you ATI+Linux users are getting when Sauerbraten exits:
http://sauerbraten.org/patch/atilinux_patch_2007_07_24.tar.gz

Extract in your Sauerbraten directory, a bin and patched source files are included. Let me know if it still crashes on exit, although it seems to fix it for me.

...

But anyway:

Okay, so today I got to try Sauerbraten on an Radeon x1300 on Linux today... and I'm appalled.

For same detail and resolution, my Intel 945GM (laptop chipset) gets DOUBLE the frame rate of a Radeon x1300.

Note, that on Windows, the card gets about 6x the frame rate it gets on Linux, or moreso.

OTOH, my 6600 in my Linux box performs same as, maybe a little better, than it does in Windows. And still outperforms the x1300 in any case.

I knew it was bad, but not THIS bad. Really, this is awful. I would RUN, not walk, to the nearest trashcan and deposit your ATI cards there.

Go to first 20 messagesGo to previous 20 messages    Board Index   

#3: Re: ..

by noerrorsfound! on 07/24/2007 14:31, refers to #1

I read about ATI's upcoming improvements on Digg some time ago. In the comments section people mentioned how ATI has claimed they would improve the drivers previously but never did. Hopefully this won't be another broken promise.

reply to this message

#4: Re: ..

by rancor on 07/24/2007 21:38, refers to #3

I'm almost inclined to believe this particular rumor though. Moving to a unified driver core would actually decrease the amount of effort required to maintain the Linux and Mac drivers. Also, they've been coming under pressure from Dell about the Linux driver performance apparently.

reply to this message

#5: VBO

by rancor on 07/24/2007 23:51

Almost forgot, the Linux drivers also have some nasty VBO issues, which cripple Sauerbraten on larger maps. I found out about this when I was trying to make Planeshift (http://planeshift.it) run faster, at which point I discovered the Crystal Space had a workaround for these issues... disabling VBO. I hate ATI...

reply to this message

#6: Re: VBO

by eihrul on 07/25/2007 01:10, refers to #5

What are these issues, specifically?

reply to this message

#7: Re: VBO

by rancor on 07/25/2007 01:32, refers to #6

They only seem to occur on larger maps, smaller maps don't appear to be affected. To reproduce, load a map like oasis. This results in a large number of the following printed to the console:
fglX11AllocateManagedSurface: __FGLTexMgrAllocMem failed!!
screen corruption, and something less then 1 FPS. This is on a 9600 with 64 MB of VRAM, and mintexcompresssize set to 64.

Googling the message turns up this thread on rage3d: http://www.rage3d.com/board/showthread.php?t=33819385
Xordan is a Planeshift developer focusing on Linux and engine work. This led me to the following comment in data/config/gldrivers.xml:
<!--
* 2005-11-22: Jorrit reports despicable performance with 64bit ATI
drivers and also states other sources would attribute a
generally poor performance to ATI Linux drivers.
@@@ Whether only certain version(s) are affected is unknown.
-->
<rule description="Disable VBO for GNU/Linux ATI drivers">

reply to this message

#8: Re: VBO

by eihrul on 07/25/2007 02:02, refers to #7

Reported in 2005 there, no less. The responsiveness of ATI's development team is unsurpassed, surely.

reply to this message

#9: Re: VBO

by eihrul on 07/25/2007 02:24, refers to #7

No problems with VBOs on the x1300, however, use of occlusion queries at all on a lot of maps seems to just entirely crash the driver.

Looks like I will just have to entirely disable usage of occlusion queries on ATI entirely until it cleans its act up.

I even feel like putting a warning message specifically about ATI fglrx performance and stability issues just so users don't blame us.

reply to this message

#10: Re: VBO

by rancor on 07/25/2007 02:35, refers to #9

I've not seen any actual crashes, though I've been unable to do much testing for obvious reasons. Which maps tend to have these crashes?

reply to this message

#11: Re: VBO

by eihrul on 07/25/2007 03:00, refers to #10

If I load up k_rpg1 or deathtek, with occlusion queries being used at all (even limiting them in number does not help), the driver takes down the entire OS.

If you don't make sure to delete all your occlusion queries before exiting, it always takes down the entire OS regardless.

My first try, like in that patch, was just to clean up all the occlusion queries on exit. But then when I noticed them locking up immediately on certain maps, I decided I won't even bother and will just disable it. fglrx performance concerns are not worth the time or energy.

reply to this message

#12: Re: VBO

by rancor on 07/25/2007 03:36, refers to #11

Hmm... deathtek presents no problem for me, however k_rpg1 appears to trigger the VBO issue, which meant I needed to kill Sauerbraten, which hard locked the system. This seems like the known and fixed issue, not anything random.
It's been a good while since I used my x700 Pro, but I believe Sauerbraten had occlusion culling then (c. late 2005 or early 2006), and I didn't have crashes relating to it. Perhaps it is an R500 problem? Support for those cards is known to be even worse then support for previous generation cards.
At any rate, I'll try to do some more testing, and see if I encounter any random hangs.

reply to this message

#13: Re: VBO

by SheeEttin on 07/26/2007 23:03, refers to #12

I experience a hard lockup when loading certain maps (e.g. vr, serenity, fightnight (http://quadropolis.us/node/697), docs (http://www.quadropolis.us/node/741)) with my Radeon X1600. Doesn't seem to be any common denominator. If it helps, two straces of an attempted load of docs [url=http://www.mediafire.com/?bnx9tyzm6dt]here[/url].

I'll try the patch, see what happens.

reply to this message

#14: Re: VBO

by eihrul on 07/26/2007 23:23, refers to #13

If it still crashes you can go into rendergl.cpp to where it sets "hasOQ = true;" and just put "hasOQ = false;" there instead, and it should no longer crash on said maps.

reply to this message

#15: ..

by SheeEttin on 07/26/2007 23:28

Patch worked for the lockup when quitting.
As for the map lockups, how does one disable occlusion queries?

reply to this message

#16: Re: ..

by eihrul on 07/26/2007 23:29, refers to #15

As I said, replace "hasOQ = true;" with "hasOQ = false;" in rendergl.cpp

reply to this message

#17: ..

by SheeEttin on 07/27/2007 01:27

Oops. Thanks. I'm really not a fan of this forum system...

reply to this message

#18: ..

by CC_machine[OnLappy] on 07/27/2007 12:16

i noticed my intel 950 (945G) in my laptop also performs a lot slower in linux... especially on large maps like mpsp6a are unplayable :( no shaders on linux, either :(

about your ATI problems with culling... is there a "toggleocull" or similiar command like in cube that will disable them?

reply to this message

#19: ..

by djGentoo on 07/27/2007 14:31

Intel's Linux drivers suck. Big-time. But so do their chips... :P And I'm even using version 2 of the drivers! This is annoying, because skycastle seems like an awesome map, but I can't get a decent FPS for it because it's so complex! :(

reply to this message

#20: ..

by absinth on 07/28/2007 21:54

>they have announced they are completely re-writing the Linux fglrx driver

nearly true, they have announced that they have written a new unified opengl driver, which should fix their bad OGL performance on windows and their abysmal (OGL) performance on linux.

incidentally their mac (OGL) drivers haven't been that bad (performance-wise).

reply to this message

#21: Re: VBO

by rancor on 08/02/2007 10:43, refers to #7

Well, this continues to be interesting... I went and disabled VBO in the source, and lo and behold, nothing changes! While that may be the problem for Planeshift, it seems that it isn't the same problem.

reply to this message

#22: ..

by SheeEttin on 08/06/2007 04:59

Well, someone put it in the source, so now patching is more or less unnecessary. Thanks.

Oh, and I like the way it displays the lightmap as it is calculated now. It's cool.

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index   


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
53415657 visitors requested 71175490 pages
page created in 0.028 seconds using 10 queries
hosted by Boost Digital