oldsk00l
02-06-05, 02:01 AM
Oh and just for measure, their suckage does not come from here...BUT FROM ATI USERS.
http://www.rage3d.com/board/showthread.php?t=33800066
Join Date: Jun 2003
Posts: 72
Default
I can also state without a doubt that enabling Vertex Buffer Objects renders UT2004 unplayable (I'm using the demo). I didn't even bother going past the main menu before exiting and turning it back off.
So much for codebase sync with catalyst....
But there's more!
After a bit of fun testing since the new driver came out I found that I get slowdowns whenever there are a lot of other players (bots or otherwise) visible on the screen. I turn around and the game runs zippy as can be, but look back at the players and the game stutters along.
I think that there are even more stutters when there is heavy action and vehicles. Even large maps run really fast if there are no other players visible.
I did not have this problem with the older driver...I had different problems
Anyone else have this same issue with the new ATi driver?
oh and this gold
http://www.rage3d.com/board/showthread.php?t=33802382
The livna team has released a repackaged version for fedora, running it now in fc2. Can't say it's stable, but that's ATi's fault I guess, since the original RPM was also unstable for me. However, as long as I don't run doom3 or restart the Xserver, it seems to be more or less ok.
find package on: http://rpm.livna.org/fedora/2/i386/SRPMS.unstable/
and something similar for fc3
Let's not forget the department of redundancy department
http://www.rage3d.com/board/showthread.php?t=33802408
Considering the patch was released 2 weeks before the driver, I say, sure they should have fixed 2.6.10 compatibility, but hey, it's ATI we're talking about here, they have "procedures".
I too used sed -i on agpgart_be.c on the previous driver revision but used the patch this time around.
I didn't quite like 2.6.10 at the time and figured it would make it simpler to build for an older kernel if 2.6.10 proved to be too much of a pain.
...the damned thing would cache in the swap during big files transfer over NFS before I patched it.
As for the libstdc++ situation, i think it has more to do with how the closed part was compiled as opposed to what it was compiled with.
I've had the 3.2.9 and the 3.11.1 driver installed on that box and never encountered any such problem before.
Looks to me like it's now compiled with --enable-static ...but I'm no expert.
One thing for sure is that it's definitely not because these older driver were compiled with gcc-3.4 and this one isn't.
Anyhow I just thought I'd hint you on the fact that you're not the only one who had to hack gcc compat libs on a non standard system and it *doesn't seem* to created unexpected side effects.
Now, can anyone with sound mind say that ATI doesn't suck??? Or, need I go further??
http://www.rage3d.com/board/showthread.php?t=33800066
Join Date: Jun 2003
Posts: 72
Default
I can also state without a doubt that enabling Vertex Buffer Objects renders UT2004 unplayable (I'm using the demo). I didn't even bother going past the main menu before exiting and turning it back off.
So much for codebase sync with catalyst....
But there's more!
After a bit of fun testing since the new driver came out I found that I get slowdowns whenever there are a lot of other players (bots or otherwise) visible on the screen. I turn around and the game runs zippy as can be, but look back at the players and the game stutters along.
I think that there are even more stutters when there is heavy action and vehicles. Even large maps run really fast if there are no other players visible.
I did not have this problem with the older driver...I had different problems
Anyone else have this same issue with the new ATi driver?
oh and this gold
http://www.rage3d.com/board/showthread.php?t=33802382
The livna team has released a repackaged version for fedora, running it now in fc2. Can't say it's stable, but that's ATi's fault I guess, since the original RPM was also unstable for me. However, as long as I don't run doom3 or restart the Xserver, it seems to be more or less ok.
find package on: http://rpm.livna.org/fedora/2/i386/SRPMS.unstable/
and something similar for fc3
Let's not forget the department of redundancy department
http://www.rage3d.com/board/showthread.php?t=33802408
Considering the patch was released 2 weeks before the driver, I say, sure they should have fixed 2.6.10 compatibility, but hey, it's ATI we're talking about here, they have "procedures".
I too used sed -i on agpgart_be.c on the previous driver revision but used the patch this time around.
I didn't quite like 2.6.10 at the time and figured it would make it simpler to build for an older kernel if 2.6.10 proved to be too much of a pain.
...the damned thing would cache in the swap during big files transfer over NFS before I patched it.
As for the libstdc++ situation, i think it has more to do with how the closed part was compiled as opposed to what it was compiled with.
I've had the 3.2.9 and the 3.11.1 driver installed on that box and never encountered any such problem before.
Looks to me like it's now compiled with --enable-static ...but I'm no expert.
One thing for sure is that it's definitely not because these older driver were compiled with gcc-3.4 and this one isn't.
Anyhow I just thought I'd hint you on the fact that you're not the only one who had to hack gcc compat libs on a non standard system and it *doesn't seem* to created unexpected side effects.
Now, can anyone with sound mind say that ATI doesn't suck??? Or, need I go further??