AMD Dropping R300-R500 Support In Catalyst Driver

[benmoran]

yes you have a r300 core or r400 but its not so importand after the 9-3 catalyst you can use the opensource driver.

Thanks for the reply. Its a shame since FGLRX works perfect on my card, and finally reached a decent level of performance in Wine. I always planned to switch to the open source driver one day anyhow, so i'll live with it.

[dkasak]

Ecomorph is marked "experimental, does not work on many graphics cards". Could I ask you to try a supported distro and window manager first, then identify issues specific to enlightenment and ecomorph separately ?

No. I've run Ecomorph on quite a range of systems, from some shitty Intel i845G chips at my old work, to my old ( now dead ) Radeon X700 ( on mesa ), to my GeForce MX something ( at work ) to my friend's Radeon X1600 ( on mesa ). Works fine in all cases. The note about ecomorph being 'experimental' is there as a standard deterrence from people asking for support if they can't build stuff from source, etc. As for using a supported distro - I use Gentoo, and no I'm not interested in switching distros to test. I was commented on my thoughts on r600 support in fglrx. As I noted later, I'm now not using fglrx, and not looking for support.

Regarding 2D performance, I think you're talking about "features" more than "quality". My understanding is that the supported acceleration APIs (XAA, OpenGL( run really fast (which is what the Phoronix articles talk about) but some programs require EXA or equivalent acceleration to avoid SW fallbacks (which is where "glacial" comes in). What I think you're seeing there is the lack of EXA acceleration (which only recently became useful in the X stack), not a quality issue.

The gdm login screen, for example, takes 1 second to render ( seriously ). I get a flashing of triangles, and then colour sweeps down across the screen until the whole thing is painted. Now I don't know what gdm might be doing other than rendering an image and 2 text boxes, but I don't think it requires EXA.

Which driver version are you using ?

I've tried the November drivers, and the January leaked drivers, and the February leaked drivers. I don't have exact version numbers. I can't quite follow what's going on between ati version numbers and gentoo ebuild version numbers, and I hacked up ebuilds for the leaked drivers anyway. But all 3 drivers are exactly the same for me anyway.

The only pauses I have heard about so far were related to PAT kernel vs driver settings a couple of months ago. This may be something specific to the distro/wm you are using, not sure. Are you running elive or something else ?

No. I use Gentoo, and I don't use PAT. And the pauses don't happen with the RadeonHD driver.

We released the docs in Feb 08, over a year ago, right ? I was there

What do you think is missing ? Devs are already working on power management code for 5xx in the open drivers using the existing information. It's power management for 6xx and higher which still needs documentation.

Sure. Releasing the docs was a good change from when I read blog posts of developers who were reverse-engineering the stuff, or a driver had been written, but wasn't able to be released. Yeah we're in better territory than that. But again, there's a difference between the existence of documentation and the existence of a working driver. This isn't just semantics. But again, this doesn't affect me directly - I have an r600, which is 'supported'

I'm sorry, what do reiserfs transactions have to do with fglrx ?

Glad you asked As noted in my previous post, I get f'n LOCKUPS when logging out ( and gdm restarts X ). After such a lockup ( magic sys rq keys don't work ), I *always* get reiserfs replaying transactions ... and occasionally lose data. This really, REALLY pisses me off, hence switching to RadeonHD and giving up ecomorph at the moment.

[krazy]

We're trying to get 6xx/7xx EXA and Xv acceleration into the open source drivers that ship with 9.04. So far so good...

That statement really made my day! can't wait

[NeoBrain]

in fakt for wine you need openGL3!!!!

you can'T get the maximum WINE Support witout DX9 or DX10 Power -->OpenGL3!

Dude... One: there is no usuable D3D10 support in Wine _at all_ at the moment. Two: You don't need OpenGL3 for that D3D10 implementation either, there are some extensions which are used by Wine, but these can also be used with OpenGL2. It's just that they were supported by NVIDIA some long time before, but only recently by ATI as it's now part of the OpenGL3 core.

[Inkaine]

According to heise online, a German IT news site, legacy support for R300 to 500 does mean driver updates will still happen once every 3 months. Not sure if that's the case for Windows only - they talk about the WHQL drivers there - but even once every 6 months (ie. with every xorg-server release) would be sufficient IMHO. On the other hand side Windows doesn't even have an open source alternative so it's more acceptable to drop support for older hardware on Linux in this respect anyways.

Source (in German): http://www.heise.de/newsticker/AMD-r...meldung/134111

[Nille]

According to heise online, a German IT news site, legacy support for R300 to 500 does mean driver updates will still happen once every 3 months. Not sure if that's the case for Windows only - they talk about the WHQL drivers there - but even once every 6 months (ie. with every xorg-server release) would be sufficient IMHO. On the other hand side Windows doesn't even have an open source alternative so it's more acceptable to drop support for older hardware on Linux in this respect anyways.

Its Only for the Windows Driver because linux has the free drivers. And about the ogl stuff qaridarium say AMD is developing the Ogl stack for the free drivers.

[Michael]

According to heise online, a German IT news site, legacy support for R300 to 500 does mean driver updates will still happen once every 3 months. Not sure if that's the case for Windows only - they talk about the WHQL drivers there - but even once every 6 months (ie. with every xorg-server release) would be sufficient IMHO. On the other hand side Windows doesn't even have an open source alternative so it's more acceptable to drop support for older hardware on Linux in this respect anyways.

Source (in German): http://www.heise.de/newsticker/AMD-r...meldung/134111

http://www.phoronix.com/scan.php?page=news_item&px=NzExOQ

I can confirm the Windows driver will receive quarterly updates, but there will be no such updates to the Catalyst Linux driver.

[NeoBrain]

According to heise online, a German IT news site, legacy support for R300 to 500 does mean driver updates will still happen once every 3 months. Not sure if that's the case for Windows only - they talk about the WHQL drivers there - but even once every 6 months (ie. with every xorg-server release) would be sufficient IMHO. On the other hand side Windows doesn't even have an open source alternative so it's more acceptable to drop support for older hardware on Linux in this respect anyways.

Source (in German): http://www.heise.de/newsticker/AMD-r...meldung/134111

bridgman already talked about that, legacy drivers for Windows, but none for Linux, as the OSS drivers will have caught up quite well with fglrx in 3 months anyways.

[MostAwesomeDude]

OGL 2.0 cards can still have some of the features of OGL 3.0, just not full conformance. OGL 2.1 cards should, as far as I know, be capable of just about every OGL 3.0 feature with a good driver.

People using Debian, Gentoo, and Fedora need to not forget that their distros are completely composed of free software, and thus their binary driver support and QA is always lacking. Furthermore, they're not on the official support list for AMD, so it should come as no surprise that extra effort won't be made to support them.

[duby229]

OGL 2.0 cards can still have some of the features of OGL 3.0, just not full conformance. OGL 2.1 cards should, as far as I know, be capable of just about every OGL 3.0 feature with a good driver.

People using Debian, Gentoo, and Fedora need to not forget that their distros are completely composed of free software, and thus their binary driver support and QA is always lacking. Furthermore, they're not on the official support list for AMD, so it should come as no surprise that extra effort won't be made to support them.

That's OK, the open source drivers are no more than an emerge away. Of course if you want git code then you'll need to use layman to install the x11 overlay, then you'll need to unmask the git versions of those packages all the way down the dependency tree. Provided that you use stable packages your only an "emerge -va xf86-video-ati" away from working open source drivers. If your installing from git then it'll take maybe an hour or so to unmask everything that you need, but shouldnt be any more then that provided that you've already gone through the learning curve.