ATI dropping support for <R600 - wtf!?

[adamk]

Frankly, even though I don't typically use the fglrx drivers, I am disappointed in this move. For example, at the present moment doom3 is only playable with the arb render path with the open souce drivers and, even then, the performance is horrible compared to fglrx. quake4 is unplayable with the open source drivers due to a lack of support for decompressing s3tc textures on the card. libtxc_dxtn is available ( http://homepage.hispeed.ch/rscheideg...3tc_index.html ) but has issues with multitexturing on the r300 driver and makes nearly every texture in the game flicker. ut2004 also gains a huge speedboost from that library, but experiences the same problem.

While I have no problems with AMD creating a legacy driver package that gets updated to support new servers and kernels, I think it's quite foolish to stop supporting them in the binary drivers altogether. Any users of those games on r300-r500 hardware (which are perfectly capable of playing those games on fglrx with good quality and performance) will be left in the cold when it comes time to upgrade their X server or kernel.

Once those items get ironed out in the open source drivers, and the remaining issues such as power-management get resolved, I'm all for dropping the from catalyst.

Adam

[DoDoENT]

For me the only real advantage of fglrx is 3D optimization. Speed in 3D applications is always a good thing, and the more you have the better, and if this is of importance to you chances are you have a rather new card, which are in turn supported by fglrx. I really don't see what the big fuss is about, specially on the Linux side.

3D optimization AND power management! And I think the power management is the most important feature that R300-R500 laptop users will miss until FOSS drivers start supporting it. I kind a expect this by June in Fedora 11, but I'm a bit too optimistic person .

And about 3D optimization - I'm a bit sad I wouldn't be able to play Scorched 3D on my Radeon 9550R (R300 card) for a while - but I'm planning to solve this by not upgrading to Jackalope or Koala. Eventually I'm planning to put openSuSe 11.2 in November or December on that computer and by this time FOSS drivers will be using Gallium3D and will be more optimized for 3D than are today.

[bridgman]

OK, maybe I'm missing something here, but...

We *are* moving the older GPUs into a legacy branch, which means you go from monthly releases to quarterly at best. That part is no different from what any other vendor does. Given that, the earliest date for the first quarterly release would be some time in June, with the next one happening some time in September (for example). Our decision was not based on the state of the open source drivers today, but our best guess about which approach will work out best at the time when the legacy driver updates would happen (let's stay with June 09 and Sept 09 for argument).

That's the time frame I'm talking about when I say that the open source approach is likely to seem like the right decision, *not* today.

The relative state of the open source and fglrx drivers *today* is only really relevent to the extent that the current state and current work-in-progress allow you to predict how the two approaches will compare later in the year.

[adamk]

OK, maybe I'm missing something here, but...

We *are* moving the older GPUs into a legacy branch, which means you go from monthly releases to quarterly at best.

This is what the phoronix article says. Please correct me if it's wrong:

AMD will be moving the R300/400/500 support to just a single legacy driver, but this branch will not be maintained. In fact, do not really look for legacy driver updates after April, as AMD does not intend to add support for newer kernel / X.Org server releases to this driver.

Having a legacy branch that is never updated to support newer kernels and X servers is not much different from dropping support entirely.

If you are thinking that the open source approach will be best approach come June or September, does that mean there are plans to tackle the s3tc issue in that time frame?

Is there some sort of development roadmap that users can look at? Over the past few years, I've seen lots of "It'll be done when it's done" answers to questions about time frames for support of specific functionality. Does this mean that there are now official time frames for certain features? While the developers will sometimes give you best guess estimates, they are often off by months/years. Are you really that confident that the r300 driver will be up to par with fglrx in terms of 3D performance and power management sometime between June and September?

Adam

[bridgman]

Having a legacy branch that is never updated to support newer kernels and X servers is not much different from dropping support entirely.

Michael is writing from a purely Linux point of view. We have a single source tree which is used to support a number of OSes. The entire tree is being moved into a legacy branch, including the Linux code. Right now we only plan to make Windows releases off that branch AFAIK.

Strictly speaking the common code in that branch *will* be updated but since we don't plan to make Linux releases off the branch it's easier to say "won't be updated" (or it just gets too hard to explain ).

If you are thinking that the open source approach will be best approach come June or September, does that mean there are plans to tackle the s3tc issue in that time frame?

It's odd, but s3tc has never really come up in discussion. Let me look into it. I think you're saying that the app is expecting the driver to *compress* textures, not just decompress them ? Presumably these are dynamically drawn textures, since static textures would be stored compressed in the first place, wouldn't they ?

Is there some sort of development roadmap that users can look at? Over the past few years, I've seen lots of "It'll be done when it's done" answers to questions about time frames for support of specific functionality. Does this mean that there are now official time frames for certain features? While the developers will sometimes give you best guess estimates, they are often off by months/years.

I don't listen to best-guess estimates any more

The sequence of events is pretty well defined right now, since the remaining integration tasks pretty much have to happen in a certain sequence, so that's the sequence in which each of the new initiatives will transition from "science project" to "real". KMS/GEM/TTM first, then DRI2/RDR, then power management and Gallium3D work can happen in parallel.

No official dates, but we don't release official dates for new features in fglrx either.

Are you really that confident that the r300 driver will be up to par with fglrx in terms of 3D performance and power management sometime between June and September?

Nope, not at all.

I am fairly confident that ON BALANCE the open source drivers will make a larger chunk of our user base happy than fglrx would with reasonable legacy updates.

Improvements to 3D require big changes but a lot of that work is well underway. For me the big milestone was seeing Gallium3D merged into master; I agree that's a totally arbitrary and fudgeable milestone but I do have a lot of confidence in the people behind the decision.

Power management is easier by comparison, since the required info has already been released and the major obstacle is waiting for churn in the kernel to settle down so power management code can be built on top of all the other new stuff.

[MikeEx]

Will you round up to the nearest 100?
r580 is close enough to r600 right?


Yeah I know, no such luck.
My main concern is if I'll be able to use Windows 7 when it's released.

[bridgman]

You should be fine for Windows 7 -- Win 7 will use existing Vista drivers (the WDDM 1.0 interface).

Native drivers for Win7 (WDDM 1.1) require DX10-capable hardware, ie R600 or higher.

No rounding allowed there AFAIK.

[tuxdriver]

This also means that upcoming Windows 7 users... won't be able to use the R300-R500 GPU's ... at all. There might be a basic driver provided by Microsoft, but they won't be getting updates. There will be no driver path.

Win7 users with legacy cards will still receive quarterly driver updates.
They won't miss anything (Aero,DirectX 9Ex) with these drivers.

[bridgman]

Yep, and Microsoft is committed to making sure that existing Vista drivers work well with Win7.

The native driver interface for Win7 requires DX10-capable hardware, so we won't be making Win7 native drivers for 5xx and older GPUs.