AMD Dropping R300-R500 Support In Catalyst Driver

[Kano]

@bridgman

Will there be Xserver 1.6 support for 9-3 driver? That + official patches for new kernel I would say could be the absolute minimum ATI has to do - even if they call it now legacy. DX9 cards from NV work with a binary driver (well basically 3 out of 4) with any Xserver - only some NV DX7 cards don't work anymore 3d accellerated.

[b15hop]

Bridgeman:
If I bought an AGP 3850 or 3650 now. How long would you expect such a card to have linux support?

[bridgman]

The answer is more complicated for Linux because the open source drivers can essentially give you support "forever", at least until the point where there is no developer interest in our products. In terms of full support in the Catalyst drivers, we don't have a hard policy but we normally aim for at least three years from when each generation is launched. It usually ends up somewhere between three and five years, but that is just "what we have done so far", not a promise.

In the case of the 3xx-5xx range, we ended up successfully using the same architecture for an unusually long time, so we ended up supporting the 3xx family for almost seven years (2002-2009). The 5xx line was introduced in fall 2005, so it had the shortest run -- about 3-1/2 years from introduction to reduced support.

Products can easily stay in the retail pipe for 5-7 years (I can still buy cards with nine-year-old GPUs locally, with no indication that they are anything but the latest and greatest other than a bit of dust) so realistically we *are* going to end up reducing support while some products are still in the stores. This is why we try to step down the support level rather than cutting it off sharply.

Anyways, if I had to guess... the r6xx family was launched in mid-2007, so I would expect the first reduction in support some time between mid-2010 and mid-2012, depending a bit on how the overall market behaves -- it's easier to provide a long support window when the market is growing as opposed to when it is flat or shrinking. Again, this is more of an issue for other OSes since programming information for those parts is already available to the X driver developers.

[b15hop]

The x1000 series did feel a little under powered, so I'm not surprised that they have been dropped. The 9700 was a very fast card for it's time and I guess why it had support for so long. I guess then it also depends on the success of the card. So I'm guessing that the current x4000 series will last a long time. Maybe not seven years but at least 4 or 5.

Bridgman:
I'm also guessing the economy has a lot to do with why things are the way they are then?
I'm really keen on doing some GPGPU in linux and i'm not so sure the open source drivers are upto scratch.

[bridgman]

The economy is a bit of a factor but in general we don't adjust R&D or support that much for short term things, whether it be market share or economic cycle. The bigger issue is that the overall market isn't growing, so we kinda have to add new products and take away old products at more or less the same rate.

For GPGPU you probably want to stick with the proprietary drivers for a while, but CAL (the bottom level of the GPGPU stack) has always been 6xx-and-up anyways. The older CTM API supported 5xx but not CAL.

There's enough info available to write an open source GPGPU toolchain today, just not many people with the right combination of skills, time and interest yet...

[b15hop]

Bridgman:
Brook looks like it was open source but it's no longer being developed?

I notice that the SDK packages, tools etc.. on

http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx

Are specifically made for Red hat or suse. What if say I want to use another distribution?

[bridgman]

I'll see if I can get "official" answers from the Stream folks, but...

Brook+ was always an open source project (based on Brook, which was also open source). AFAIK it is still being maintained but now that the OpenCL standard has been ratified we're also putting effort into delivering an OpenCL implementation. We have always believed that GPGPU needed cross-platform tools in order to be broadly accepted, so we have always focused on non-proprietary solutions (Brook, Rapidmind etc..) wherever possible.

I don't think the SDK is locked to RHEL and SLE* any more than fglrx is; they just happen to be what we see as the primary target platforms based on customer feedback, and so that is where we focus our test and support efforts.

As far as I know the tools are all userspace and run over fglrx on Linux, so they should be relatively distro-independent.

[b15hop]

I agree that OpenCL looks like the way to go. If only it was in development a little sooner.

[bridgman]

It was, but the standard kept changing

[b15hop]

Hmm If OpenCL drags on for 3 years before a 1.0 release, at least it will be more concrete. But in saying that, by the time it's properly released, DX will be phased out with something new to. Plus two or three generations of new cards would have come out. r600 / r700 might even be phased out before a proper release.

EDIT: Actually. I'm thinking the standards ARE changing just because of the shear rate of hardware updates. So OpenCL might end up on a choppy path for some time. With constant updates much like the gcc compiler is updated for every architecture update. I'm guessing there will be a plethora of new problems too, with regards to portability of code. Ie. Graphics card (A) might have different features that graphics card (B) has. Newer cards will have (A + B + more) features. Think Nvidia and ATi/AMD here. Assuming they are the only two, but most likely not.