Should AMD make kernel and Xorg-server updates for their legacy drivers?

[smlbstcbr]

So, that's the question. I think that making kernel and xorg-server updates to their legacy (starting in a couple of months) drivers won't hurt AMD.

[Melcar]

I think they should. Even if it's not that frequent; don't do it for every single kernel and xserver release but rather for every other release or something. Then again, people that really need the 3D performance are bound to be running fairly new hardware already, so for people running older hardware the open source drivers would be a much better choice than running a legacy driver that is not updated.

[RealNC]

I'm not affected, but I think they should update it once in a while. NVidia does :P

[tball]

If I had a legacy card, all that would matter to me was video acceleration and basic 3d acceleration. This is the opensource drivers already able to deliver, so I don't think fglrx is needed. I don't have a legacy card, but at the time it gets legacy, we will probably have very good opensource drivers.

[Danyul]

While I voted for doesn't matter, It would be nice to see the legacy driver updated to match the current stable Ubuntu/Fedora releases.

If they are going to bother with an fglrx-legacy then I would think it's the best path to take. Otherwise the driver becomes useless the same month it's released.

I think people should just use the opensource option for these legacy card though. I've got an ATI Mobility X1400 currently in my laptop (I can swap it out for a the NVIDIA GeForce 7300 Go, but there's no overwhelming performance advantage) and it runs better on the radeon driver than it does on fglrx.

Not to mention great xrandr support etc. We've got a lot of specs for the AMD/ATI cards and this is moving developments along at a very acceptable pace.

Good work and my thanks to all involved.

[Saist]

My take is this: No

I'd rather AMD focus engineers on keeping the FGLRX packages optimized for currently shipping hardware. Lets be honest, Radeon x1800's and x1900's really haven't been on the market for a couple years now. Supporting the older cards and chipsets requires developer and engineering time that AMD simply can't afford.

I'd rather the X.org community, be it Linux, BSD, or whatever, focus on supporting the older hardware with the documentation provided by AMD. I think there are business opportunities to be had for small business's to set up external support and driver development.

[RealNC]

If I had a legacy card, all that would matter to me was video acceleration and basic 3d acceleration.

My old X1950XT can do far more than "basic" stuff. I was gaming with that one until quite recently. It's a gaming card. And for gaming cards, the open source drivers suck.


This is the opensource drivers already able to deliver, so I don't think fglrx is needed.

Exactly. You "don't think."

[DoDoENT]

My take is this: No

I'd rather the X.org community, be it Linux, BSD, or whatever, focus on supporting the older hardware with the documentation provided by AMD. I think there are business opportunities to be had for small business's to set up external support and driver development.

I agree. But the fact is that most of the FOSS driver developers focus on supporting the newer graphic cards, that are also supported by fglrx. And legacy card owners are left in the dark.

My old X1950XT can do far more than "basic" stuff. I was gaming with that one until quite recently. It's a gaming card. And for gaming cards, the open source drivers suck.

Exactly. With both of my ATi cards (Radeon 9550R (R300) and Mobility Radeon X1600 (R500)) I can't play Scorched 3D with radeon driver properly. It works only with minimum details. OTOH, with fglrx it works on both cards like a charm (with medium/full details).

[Saist]

My old X1950XT can do far more than "basic" stuff. I was gaming with that one until quite recently. It's a gaming card. And for gaming cards, the open source drivers suck.


Exactly. You "don't think."

Neither do you.

A: if you are a gamer who bought an x1800 or x1900 new, you'd already be budgeting for a better graphics card, or you'd have a better graphics card. Like it or not, the x1900 and x1800 aren't outpacing a "new" gimped HD 4650 (400mhz ram versus 500mhz ram) by that much.

So knock off the "I'm a gamer and I expect my 3 year old gaming card to still run the newest games with a decent frame-rate." That argument holds no weight.


B: Okay. the current open-source drivers suck in terms of 3D performance. NOBODY IS ARGUING THAT. Nobody's saying the Open-Source drivers are great for gaming right now. However, all of the existing limitations to the drivers are already recognized. Major changes to the driver structure are under development right now. When those changes are complete, the performance delta's will close up.

Okay, that is going to take some time to accomplish, it's not going to happen overnight. Most people get that. Many people seem to be willing to help that change happen, either by donating time to code, or hardware / money to people who CAN do the coding. Sadly, Many more see fit to scream and cry in forums rather than get involved in the projects.


C: Nothing is stopping you from using the existing 8.x or 9.1-9.3 drivers right now. Like or not, I have support for 3D acceleration on a Radeon 9600. I can play City of Heroes or World of Warcraft. I can utilize many games in WINE. I can play Doom3, Quake 4, Eve Online, and so on natively. I can run Compiz-Fusion. I can rotate my screen. I have a fully functional driver, RIGHT NOW.

Okay, so it doesn't support KMS, whatever that is. It doesn't support X-server 1.6. It doesn't have the latest and greatest 2D support. I can live without that. Those features don't radically change my Linux desktop experience.


I agree. But the fact is that most of the FOSS driver developers focus on supporting the newer graphic cards, that are also supported by fglrx. And legacy card owners are left in the dark.

Then get involved. I don't know driver coding, but I'm trying to learn it so that I can at least contribute SOMETHING to the driver development. I have a couple of 9600's, a Radeon 9100 IGP, an x1900 AIW, and an x1800 XT that are still in "daily use systems." I don't want to see support for those to go away, and I doubt others want to see support go away as well. Just from some of the trolling and whining here, it's obvious there IS a market to support the older cards with performance drivers... and the information is out there to get performance equality (not just parity) with the existing proprietary driver.

I would hope that more people would rise to the challenge and start coding, or learning to code. The more people submitting code, the better the drivers will be.

As I see it, Legacy owners are only left in the dark, IF THEY WANT TO BE LEFT IN THE DARK.

[RealNC]

Neither do you.

A: if you are a gamer who bought an x1800 or x1900 new, you'd already be budgeting for a better graphics card, or you'd have a better graphics card. Like it or not, the x1900 and x1800 aren't outpacing a "new" gimped HD 4650 (400mhz ram versus 500mhz ram) by that much.

So knock off the "I'm a gamer and I expect my 3 year old gaming card to still run the newest games with a decent frame-rate." That argument holds no weight.

You're not getting the point. The card runs the games I bought it for perfectly. Did I ever mention that I want to play the latest titles with it? I've got an HD4870 for that.

The X1950XT runs the older titles, and quite a few newer ones perfectly.

What's your point exactly?

[adamk]

So knock off the "I'm a gamer and I expect my 3 year old gaming card to still run the newest games with a decent frame-rate." That argument holds no weight.



The argument "I'm a gamer and I expect my 3 year old gaming card to still run 3 year old games with a decent frame-rate" is valid. Unfortunately, with the open source drivers, as they currently exist, it won't be possible.


When those changes are complete, the performance delta's will close up.


And, at that point AMD should feel free to drop support for those cards.

Adam

[Pfanne]

they should support the cards with kernel updates until we have usable gallium3d drivers, that work with games...
its not about 100% speed in games, but the games should at least work...

[linzerd]

IMHO they should, because their definition of legacy isn't quite right. x1950 isn't legacy for me, here in Venezuela it is still a gaming card (for Windows and Linux), and there are things that the open source drivers can't do yet...

[dungeon]

The argument "I'm a gamer and I expect my 3 year old gaming card to still run 3 year old games with a decent frame-rate" is valid. Unfortunately, with the open source drivers, as they currently exist, it won't be possible.



And, at that point AMD should feel free to drop support for those cards.

Adam

It is always possibile, just use latest supported kernel and Xorg-sever or use some LTS distro. If you use/choose Ubuntu 8.04 you will have support until april 2011, but if you choose Gentoo you have even now opensource driver which is many times better than GDI on W7:D.

@#
I was experiance ATI support dropping for my 9250 card in 2006 in Linux and Windows, so this is perfectly understendible to me, even rV280 chip was first time presented just two years before in middle 2004... So what this poll tend to achieve, when AMD also says that newer fglrx from 9.4>= will NOT provide kernel and Xorg-server updates?

I'm THE GAMER and i use radeon/Mesa/DRI driver:
http://i263.photobucket.com/albums/ii149/smokidungeon/Screenshot-WorldofGoo-1.jpg
Dropping support signify: "From now you may/must do something MORE because of your unsupported product"-the Sign Painter.:D

[smlbstcbr]

So what this poll tend to achieve, when AMD also says that newer fglrx from 9.4>= will NOT provide kernel and Xorg-server updates?


It's just a poll to see how the community (I mean, we the people that like to use their beloved now-to-be-obsolete Radeons) thinks about the AMD announcement.

[grantek]

Yeah, I thought the prevailing sentiment would be "Duh!", but there's actually a lot of people that voted for options 2/3 :)

[Nille_kungen]

I think they should keep the legacy driver updated to xorg and newer kernels at least for 1 year.
Then i think the open source drivers will be good enuff to use.
They don't need to fix anything else, only keep it useable.

[pedepy]

bottom line is this is hardware i paid for, and I will not ever be satisfied with anything less than getting the full 100% performance it can deliver. I really don't see how you could make a point for anything less than that.

So I just read that x server 1.6 won't be supported with the 'legacy' driver. This is to say I will never be able to upgrade my input device drivers/kernel/other hardware drivers because of ati.


this blows.

[Melcar]

Been using the open source drivers for a while now. For regular desktop use on my old cards (mostly r4xx chips) they offer a great user experience, and right now the only advantage fglrx offers over them is better 3D performance. Once Gallium and all that good stuff hits the streets, I really don't see why anyone in the desktop arena with a legacy card would bother with fglrx anymore.

[DoDoENT]

Once Gallium and all that good stuff hits the streets, I really don't see why anyone in the desktop arena with a legacy card would bother with fglrx anymore.

And when can we expect Gallium? It doesn't look like it'll be ready for usage soon, or am I wrong?

[fat_chris]

So knock off the "I'm a gamer and I expect my 3 year old gaming card to still run the newest games with a decent frame-rate." That argument holds no weight.

I have a x1900xt and can run new games with decent performance (in windows of course). I haven't exactly measured my FPS because I don't really care about it, all I care about is whether games play well, and they do.

[dungeon]

DoDoENT
And when can we expect Gallium? It doesn't look like it'll be ready for usage soon, or am I wrong?

Overall Gallium is allways ready i think (it works for intel, but that drivers Tungsten developed - r300>= are community developed driver only!), but lagging is because radeons don't have any memory manager "yet" (funny word) and showstopper also is because someone make up KMS thing for which drivers must to ex/im/plode. I think, all just sits and wait for things to happen... i mean devs... So, i think, users will wait some years for that, but who knows maybe something happens "internally" (bridgman's word). He promise classic Mesa/DRI drivers for HD card/s "soon" (funny word), but no one even mention who is responsible to make memory manager and when this will happen... deep sigh.

[bridgman]

but no one even mention who is responsible to make memory manager and when this will happen... deep sigh.

There are really two parts to the work; the memory manager itself, and the fairly big changes which need to be made in all of the OTHER components in order to make use of the memory manager.

At the risk of stepping on TIRDC toes...

Airlied is working on the memory manager and it has been running for some time in the Fedora development trees. Anyone running KMS on a Radeon GPU is using the memory manager already. The memory manager was running last fall, but it (along with DRI2) was pulled back in order to build a GEM API on top of the existing TTM code.

The memory manager uses an initial TTM implementation which is not felt to be ready to go into the upstream kernel tree without some cleanup, so right now the memory manager is only available in the Fedora development repositories (although I think the code has been experimentally pulled into a couple of other distros as well).

My understanding is that Thomas at TG (now VMware) has released some new TTM code which Airlied is hoping to integrate soon, but I'm not 100% sure about that last part or whether the changes are enough to let the resulting code go into the upstream kernel tree.

There is a branch of xf86-video-ati (aka radeon driver) which runs over the memory manager, and an early version of this code (along with KMS and memory manager) shipped in F10.

The r3xx-r5xx classic mesa driver has been modified to use the memory manager (airlied, glisse, nha mostly AFAIK), and airlied then merged r1xx/r2xx support into the r3xx-r5xx mesa tree (in the "radeon-rewrite" branch) rather than separately adding mm support to the r1xx and r2xx mesa drivers.

Internally we are working on adding initial 6xx-7xx support to the classic mesa driver. That work was built on the pre-mm mesa code rather than the work-in-progress changes to support mm in mesa. We got surprised a bit by the progress on radeon-rewrite (which uses "bufmgr" code to provide a common interface for mm and non-mm environments) and we are going to change our code to be compatible with radeon-rewrite since it is likely to merge into mesa master before our code. Not sure of the schedule impact yet, but since radeon-rewrite is getting close to merge-ready state we really need to match up with that code immediately.

[dungeon]

Thanks for explaination, it IS a hard work when user see the bigger picture! OK, airlied is responsibile to prepare/pick/negotiate MM and KMS to be ready both for Mesa/DRI and kernel and you have your HD driver almost ready code and radeon which are now and will be non-mm capable when airlied is merge ready? As i understood, you basically must wait for that merge to see if changes will be needed and then from that stage we can expected new ogl features to be added for DRI radeons?

All together, that is a lot of work:rolleyes:! I'll bet maybe, two years or more to become ogl-2.1 ready;) It will be OK schedule for me, but don't know for others:).

[DoDoENT]

I'll bet maybe, two years or more to become ogl-2.1 ready;) It will be OK schedule for me, but don't know for others:).

So, in these two years it would be very nice if AMD made kernel and XServer updates for their legacy driver...

[bridgman]

But then it would take even longer :D

There's more work going on than what I mentioned above. MostAwesomeDude is also making great progress on a Gallium3D implementation for r3xx-r5xx parts, built over DRI2 and GEM/TTM/KMS. Once our guys get basic 3D running on 6xx-7xx they'll probably work on Gallium3D as well.

The cool thing about Gallium3D is that "in theory" all of the higher level Mesa changes to deliver GL 2.x are already in place, and once the Gallium3D driver comes up then those higher level functions will start to light up as well. Obviously it's never that simple in practice but it does mean that a lot of the GL 2.x work is already done.

[Kano]

How about an official fglrx patch for 9-2 (and next 9-3/9-4) for kernel 2.6.29? The only unofficial one which worked is >1700 lines, nothing that I like.

[dungeon]

But then it would take even longer :D

Thats for sure:D.

[d2kx]

So when TTM is going into the kernel - what benefit do we get from GEM?

[Kjella]

So when TTM is going into the kernel - what benefit do we get from GEM?

GEM is the kernel API, which is very high level and generic. It essentially only divides memory into different domains and lets you manipulate those. TTM is a much more detailed interface which worked well in many cases, but turned out didn't work well in every situation but it's still in use, just not as a kernel interface, The result is that some drivers have a meta-layer implementing TTM on GEM. Like:

a) Mixed GEM/TTM

GEM (kernel)
------------
TTM on GEM
Driver on TTM

b) Pure GEM

GEM (kernel)
------------
Driver on GEM

Least, that's my understanding of it.

[bridgman]

Yep, that's about right, although it's actually GEM on TTM (GEM API is supported, but the GEM API calls are handled using some TTM code).

By the time GEM came out most drivers already *had* TTM implementations. There were some aspects of the proposed GEM API which the devs really liked, and others which didn't seem so broadly useful, so the resolution was to make part of the API driver-specific and standardize the rest.

Most drivers are now implementing the standardized part of the GEM API but building it over their existing TTM code. As a result, it's the GEM API that will be exposed, but if you look inside that GEM code for non-Intel parts you'll find most of TTM. Something like that, anyways.

[cutterjohn]

Like it or not, the x1900 and x1800 aren't outpacing a "new" gimped HD 4650 (400mhz ram versus 500mhz ram) by that much.Wot!
Memory
Type GDDR3
Clock 850MHz (this is what newegg, etc. would call 1700MHz and really isn't that far below stndard desktop clocks)
Size 512MB
Bandwidth 54.4 GB/s

...

Core clock 500MHz (this OTOH is quite a bit lower than standard desktop, and doesn't overclock close to those...)

ATI Mobility Radeon HD 4850 (note this is a mobility part, and even here the clocks are only slightly reduced from the desktop)

(Under windows, catalyst will overclock it to 910/550, although I don't run it overclocked. Plus this nb has a built in FSB overclock of 14-25% which I also don't use... MSI GT725-074US)

Anyways, I don't know enough about the state of the OSS drivers to realistically vote. This is my first computer w/an ATI card in something like 7y! So, my $0.02 is if the OSS drivers are good enough to run 3D apps that are reasonable for those older cards, then I'd say don't worry, run the OSS drivers.

(My desktop still has an eVGA 7600GT KO(planning to upgrade at some point), yet it still can run games @ 1280x1024(max res CRT) or 1024x768 and decent graphics details, so I wouldn't blithely dismiss older cards either. (Contemplating a 4870 GDDR5 IF my ATI experiment w/this nb goes well... o.w. an nVidia g200 of some type.)

[Dinth]

If developing of legacy drivers could slow down development of main line, they should be abandoned.