Open-Source 2D, 3D Drivers For ATI Radeon HD 5000 Series

An anonymous reader writes "AMD has now rolled out open-source 2D and 3D drivers for their ATI Radeon HD 5000 series graphics processors. As described at length over at Phoronix, it's taken nearly a year to complete but there is now public code released that enables 2D, 3D, and video hardware-acceleration for this latest generation of ATI GPUs. For now this code is intended for developers and enthusiasts but with time it will make its way into stable Linux distribution updates. AMD's open-source developers are also beginning to work on ATI Radeon HD 6000 series support, which is hardware not to be released until late in the year."

Comments

nVidia

[Snaver]

I guess this is more than what nVidia has been doing.. Plus for AMD users.

Re:nVidia

[Threni]

That's why I got an ati card for my ubuntu 10.04 64 bit. I didn't see any other choice!

Re:nVidia

[TheRaven64]

And security holes get fixed faster. nVidia has a bit of a history of leaving security holes wide open (including a remotely exploitable hole that let a malicious png execute arbitrary code in kernel space, which they left for two years). I was recently talking to one of the Noveau developers, and it seems that this hasn't changed recently - they still haven't fixed the hole that he reported to them a year ago.

Doesn't help with all the older cards.

[aussersterne]

After years of being a die-hard Nvidia-on-Linux user, I took a risk and went with a laptop that had integrated ATI graphics when I made my most recent upgrade.

Nothing but instability, incompatibility, artifacting, underperformance, a mess. I regret it. I finally got an IBM Advanced Mini-Dock and put an Nvidia PCI-Express 8600GT in it (needed something low power enough to draw from the slot alone, small enough to fit in the tiny mini-dock space).

Installed the Nvidia drivers and away I went, stable and fast.

Meanwhile, on Windows nobody (neither IBM nor Lenovo nor ATI) have managed to release updated, much less Windows 7-compatible, drivers for the integrated ATI graphics in my Thinkpad. The machine is only two years old but it's all EOL as far as ATI is concerned.

This is a good move by ATI, I suppose, but it's woefully late, and it doesn't do anything about existing hardware on any platform. ATI's hardware might be okay, I have no idea, but their driver support on every platform sucks ass.

And they suck.

[aussersterne]

This is on Fedoras 11, 12, and 13 with a Mobility X1400. I've tried both radeon and radeonhd. I tried dozens of options and no options.

Crashes. Freezes. Panics. Unpredictable behavior (woah, garbage screen, hit CTRL-ALT-BKSP to restart server, hey, now it works, but two hours later, woah, garbage again!).

I gave up on the 3D support but even had trouble and unpredictable behavior with the 2D support, especially with Xrandr and dual monitors.

Thought for a moment that it might be worth it to try the closed-source drivers but of course the X1400 isn't supported in the current version and the older version that supports the X1400 would require that I step half a dozen Fedora versions back. Not gonna happen.

I've been a Linux user since 1993, when I retired an old Sparc+SunOS system. But I find that the older I get, the less patience I have for the ideological morass that is the Linux community.

- Just because a driver exists does not mean that it works
- Just because a project exists does not mean that it works
- Submitting a bug report no longer helps it to work
- Submitting a patch is generally the same as submitting to /dev/null
- Generally, submitting a either generates (1) ridicule, (2) lectures, or (3) work

Seriously, before simply docking the laptop and running Nvidia, I was crawling through bugzilla applying patches to the source RPM for the Xorg nvidia driver to fix things as basic as icon corruption.

Of course, many of the patches were submitted months or even years ago, so they no longer cleanly apply and have to be adapted. You can choose (if you want to avoid 2D corruption with the X1400) either to re-patch and re-compile by hand each time an Xorg update comes down the pike, or you can exclude Xorg updates in yum. Neither is acceptable, but it must be done if you want to avoid screen corruption with a Thinkpad T60 2007-xxx model. Why haven't the patches been included in subsequent releases, given that they fix the issues in question?

I'm sure there's some perfectly good ideological reason having to do with some form of code (or even development process) perfection. Of course, such reasons have nothing at all to do with making code that actually _works for users_.

This mirrors my experience of bug reporting with KDE and GNOME projects. Take the time to install the symbols binaries and generate nice bug reports and what you get are nontechnical explanations of why you're doing something wrong (wrong hardware, wrong preferences, wrong use cases, whatever) rather than any interest in actually making software work for users.

Meanwhile, Snow Leopard as a hack runs better and more stably than Fedora 13, even with the binary Nvidia drivers.

Re:Now for your part

[whoever57]

We've got to reward the companies that do this.

But how does ATI know that you bought an ATI card because of the open-source drivers?

Perhaps an alternative (and cheaper approach) is to go and download the drivers from ATI's website while using a browser that sends a user agent that is clearly identifiable as a Linux system.

Re:Now for your part

[symbolset]

I'm in favor of this, so let's give AMD some proper recognition. I deal a lot with AMD servers and bladeservers as well as the Intel ones. The memory architecture of recent AMD servers is four channels rather than Intel's three. This allows for configurations of memory that are in the more familiar powers of two, as well as providing 1/3 more memory bandwidth. In some cases the AMD servers offer more net memory. In addition it allows more special things, like 256GB on a two processor server, which Intel currently can't do in a retail server.

The AMD twelve-core servers open the possibility of a terabyte of RAM if you're looking for that. They considerably alter the cost-benefit analysis of Virtual Desktop Infrastructures (VDI).

AMD has done away with the multi CPU premium, so as your real world problem scales the cost of servers scales linearly rather than logarithmically - up to the point that your problem can be solved with 96 x64 cores.

The cost point now isn't about the CPU, it's about the RAM.

Re:OpenGL?

[RAMMS EIN]

I wonder how much of the OpenGL stuff is actually in the hardware, and how much is in the software. With my limited knowledge and understanding, it seems to me that modern graphics cards are mostly execution engines for instructions that perform simple, primitive operations, and that most of the OpenGL support is actually in Mesa, with the driver mostly being there for allowing communication from Mesa to the hardware, and some non-Mesa things which I imagine would mostly be non-OpenGL.

Within Mesa, there is, or at least used to be, an implementation of OpenGL that runs on the CPU. This could be used to provide OpenGL compliance, without any support from the graphics hardware, but it would be extremely slow. Support for 3D on specific chipsets consists mostly of implementing whatever OpenGL specifies in a way that makes it fast on that chipset. If the chipset has a dedicated function for a feature, you can use that. If the chipset has primitives that you can use to implement the feature, you can use those. If all else fails, you can use the code that runs on the CPU as a fallback.

Assuming all the above is correct (and I would like someone who actually knows these things to weigh in on that), the answer to your question would be that the open-source support for OpenGL can be as correct w.r.t. the specifications as people care to make it; AMD isn't much of a factor in this.

Re:What about OpenCL / FireStream programming?

[TheRaven64]

nouveau does not support CUDA nor OpenCL yet

One of the projects I've recently been involved with is a GPGPU compiler for nVidia cards using a friendly fork of Nouveau. The interfaces to the compute units have been reverse engineered, as have the instruction sets for the compute shaders. This means that we are currently able to load and run GPGPU programs compiled without any nVidia code. So, there is enough information available to implement OpenCL for nVidia cards, meaning it's likely to appear in the next few months.

Re:Here is your benefit

[Little_Professor]

The benefit is: If it crashes, you can do something about it.

Sure. And how often have you re-written and recompiled an open source graphics driver? In fact, how often have you even bothered to look at the source?

For the vast majority of users, a driver that just works is preferable to a an open-source mess of a driver that has awful performance

Re:Excellent

[jonwil]

Good luck getting VDPAU in the open source drivers.
Apparently, releasing the specs required to support the hardware video decoding in the ATI chips would compromise Windows based DRM (i.e. where the app decrypts the video file and sends decrypted but compressed video data to the video card, the specs for the video decode part would let you build a program to intercept the compressed video data before it gets sent to the card)

Re:Here is your benefit

[Kjella]

mode="Devil's advocate'. And I say this as the owner of a HD5850...

The driver will be longer supported then AMD or Nvidia ever would do;

Can be. Will be implies that there are people that would, but there's no abundance of volunteers.

KMS is nice to have;

nVidia's drivers don't use KMS, and are very well featured. Why would a closed driver need KMS?

3D effects like Compiz or Kwin should run better because they can fix any bugs in the driver faster;

Assuming those projects will bother to fix drivers and not just say "fix your driver, it works with software rendering".

someone can port the driver to *BSD or Heiku or BeOS or some other system;

We could also have OpenGL 3/4 support by now. But we don't, not even in mesa... Still, I suppose in theory it's nice.

you don't need to install the driver again and again only because of an kernel update;

With DKMS this does not seem to be an issue unless the kernel interfaces have changed. Actually xorg updates are a much bigger headache.

you don't have to install the driver at all and your system will just run;

True. But modern distros have made this as easy as checking off a tickbox, it's no longer a complicated procedure.

Code from the driver can be reused and the driver itself can reuse other code, that means less bloat and more security and stability in the kernel;

I would not be touting the horn too much about that one. Closed source drivers share code between all three platforms (Win, Mac, Linux) so they draw upon far more resources than all the OSS work on Linux combined.

Can't they just release the specs?

[davidwr]

Wouldn't it make more sense to release the specs ahead of time so people could write their own drivers?

Oh wait, they want to keep the secret sauce for competitive reasons.

Okay, release enough specs and maybe even a reference driver that doesn't tell you how to take advantage of the novel features of this board, then release updated specs every 6 months with things that competitors' boards can do as well.

Also, these days, unless your hardware is doing a truly revolutionary or niche task, there's no reason not to let it pretend to be compatible with existing but inferior equipment for which there are already open-source drivers. New network card? Have a compatibility mode so it can do "basic" operations at 100mb/sec. New graphics card? Have a compatibility mode with a well-know, open-source-driver-available circa-two-years-ago-at-your-current-price-range-but-now-dirt-cheap video card. New sound card? Ditto.