Slashdot Mirror
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."
Since the 5x00 series cards also included built in audio for the HDMI connection, did ATI also make drivers which support the full functionality? Or is this just video only?
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
Uhm. ATI has OpenSource drivers for _all_ hardware starting from r100 for Linux. And all their drivers support KMS.
They just include a Realtek soundchip on board that handles the HDMI audio. So you'd have to look to Realtek for OSS drivers as ATi themselves doesn't control the code.
ATI HD5770 or nVidia GTX260 or GTX460. If you want to be able to use the latest in OpenGL 4.x and OpenCL, you'll want to go with ATI HD5770 or GTX460.
Radeon firmware is used to program a few special-purpose chips on the board. Up until the HD series, firmware was only needed to start up the DMA engine and get acceleration going; modern cards need a second piece of firmware to enable interrupts, for e.g. low-latency audio and vsync.
If anybody ever wanted to go out and reverse-engineer these blobs, they could, but it's really not worth the trouble since the level of functionality is so small and AMD already gives us bugfixes for the ucode when needed. That time might be better spent figuring out the patented parts of the chipset (video decoding, texture compression) which AMD isn't allowed to document for us.
~ C.
Traditionally, nVidia had high-quality but closed drivers for Linux, while ATI had a low-quality but open ones (they also had a closed one, but it was pretty bad too). The main change seems to be that ATI's released a lot more specs lately, and has devoted more attention to producing non-crappy Linux drivers.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
The fact that they're open source means they'll soon be able to support kernel mode setting, and integrate better into Linux distributions than Nvidia's proprietary stuff.
This reply post contains many errors and is not at all informative. The grandparent asked for video cards that work well with open source 2D/3D drivers, the ATI card he cites only has experimental support only, and will probably not be functionnal for a while, and those 2 nVidia cards he cites have no working 3D driver AT ALL. Please mod that post down to the basement.
The correct answer to his question is:
buy an ATI Radeon X1900 or less video card, I suggest the X1650. These cards have good open source 2D/3D drivers, where released within the last 5 years and can run the applications you mentioned. Anyting more recent would probably be less stable, but will improve over time, and Intel does not build "video cards".
You probably don't need a 5770, you can get a 4770 for about $30-60 cheaper and it will likely be more than enough. I can play any game out there right now on high settings at 1680x1050. If you run a higher resolution you do probably want the 5770. In
Gallium now also has LLVM to optimize performance.
Last I heard from the Gallium guys, they'd given up using LLVM for anything other than the CPU fallback path because of the double mismatch between TGIR and LLVM IR and between LLVM IR and how GPUs actually work. LLVM is a low-level VM in the same way that C is a low-level language: i.e. only if your target looks a lot like a PDP-11.
The nice thing, in theory, about Gallium, as you say, is the separation of state trackers from the back end, meaning you don't have to implement most of an OpenGL stack in your driver. In practice, this doesn't seem to be saving as much effort as was first thought.
I am TheRaven on Soylent News
Says someone who's never had to try and update the latest version that supported his card by hand to make it compatible with the latest kernel. Linux doesn't have a stable driver/module interface, and that makes closed-source drivers an absolute pain.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Warning: This post contains some massive oversimplifications. If you have worked on 3D drivers, then you will probably find reading it to be quite painful...
A modern GPU actually does very little that is graphics specific. It is basically a stream-vector coprocessor. It's as much a general-purpose processor as the CPU, it's just optimised for a very different workload. The CPU, generally, is optimised for integer-heavy code with a branch roughly every 7 instructions. The GPU is optimised for doing more or less the same sequence of floating point operations to a large number of inputs with branches every few hundred instructions. You can run any algorithm on either, but any given program is likely to be much faster on one than the other.
All of the OpenGL bit is implemented in the OpenGL state tracker. This may be part of the OS or part of the driver, depending on your target platform. This keeps track of all of the API state and issues commands to the hardware. The hardware basically (meaning, this is a really massive oversimplification) understands three commands: copy data to VRAM from RAM, copy data from RAM to VRAM, run program. All of the clever stuff is done using the third command, which runs some program (generated by the driver) on the GPU. There's also some other stuff for controlling the DAC or DVI/HDMI/DP outputs, but this is a relatively small part of the driver.
With Gallium, the state tracker is completely isolated from the back-end drivers. For OpenGL, the state tracker is MESA. This generates programs in TGIR, which is an abstract instruction set that is designed to look like a GPU. The back end driver then compiles these for the target GPU (or CPU if the GPU doesn't support them) and runs them. All of the OpenGL-specific code is in Mesa, and is shared between all drivers. You can remove this and plug in an OpenVG or XRender state tracker (or even a Direct3D one, if someone wants to write one) to expose a different API (or you can plug in several at once) and the driver is completely unaware of this. It just compiles and runs the programs that the state tracker generates.
In contrast, the older DRI drivers and the blob drivers contain their own state trackers. In the case of the DRI drivers, they contain a copy of Mesa (or just have some back-end code in the main branch of Mesa). In the case of the ATi and nVidia blobs, they have a complete OpenGL implementation.
What you describe is basically how the old drivers worked. It's a lot of effort to maintain those, because the OpenGL spec evolved a lot over time, and now cards don't actually support any of the stuff that the old interfaces specified directly, the drivers just generate programs that the card uses to run them. It's also problematic because it ties the driver to a specific API, so if you want OpenVG or XRender support, you need to either write a new driver or implement these APIs on top of OpenGL, rather than running them directly on the card.
I am TheRaven on Soylent News
But from what we are seeing now AMD have made steady gains and have reached a point where they are releasing an OSS *driver* (albeit an immature one) for their latest GPU series less than a year after the hardware was released. Being able to 'drop' support for the proprietary drivers on legacy hardware earlier (in favour of the OSS driver option) will free up more developers within AMD to work on drivers for the latest GPUs. As the OSS driver team become and more more integrated within the workflow of the company we can expect to see OSS driver code and documentation get closer and closer to the hardware releases.
In short it looks like things are paying off for AMD and the OSS driver strategy. Keep up the good work AMD!