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."
I would have had the first post, but I was waiting for my browser window to scroll.
Be relentless!
I guess this is more than what nVidia has been doing.. Plus for AMD users.
http://www.snaver.net/
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.
STOP . AMERICA . NOW
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"
These days, I pretty much only buy motherboards with intel graphics, simply because I don't want to have to deal with the hassle of installing NVidia's closed drivers, and for the life of me I can't figure out what I am supposed to do with an ATI card. There seems to be half a dozen open source driver projects always on the go, with no clear indication of what cards work and what cards don't. Add to that the constant complaints I see over their own closed source drivers, and that's another brand I simply won't consider. Someone tell me I'm wrong and point me to something that can clarify the situation.
Go out and buy some. And then help to make the driver rock-solid, if you're capable.
We've got to reward the companies that do this.
Bruce
Bruce Perens.
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.
You're reading far too much into Bruce's statement.
If buying ATI cards because of their improved performance encourages ATI to make a greater investment in open source drivers, which in turn further improves features and performance, how is this is any way NOT pragmatic?
There may be such a thing as open source zealotry, but, when they choose it, the vast majority of people choose FOSS because it's better than the alternatives.
Lastly, accusing Bruce Perens, of all people, of zealotry is not a great way to impress us with your perspicacity.
Crumb's Corollary: Never bring a knife to a bun fight.
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.
There are many issues in the world that can best be solved by people being nothing like you.
Simply put: If the consumer doesn't reward good deeds, business (with it's legal obligation to maximize profit) won't do as many good deeds.
In this case, your pragmatism, along with that of millions of others, is partly to blame for closed source drivers are so common. You yourself probably have lower quality graphics or operating system functionality due to this.
While it's fine to be pragmatic in many circumstances, your stance that buying on principle isn't morally above buying through total pragmatism is, IMO, ultimately harmful.
Blood diamonds are an extreme example of what comes from mass pragmatism. Would you knowingly buy one it it was better value?
You agree with me.
Bruce said "we've got to reward the companies that do this" not "we've got to punish the companies that don't." The former is pragmatism -- seeking to achieve and support a positive result (vendor provided open source video drivers) through reasonable means. The latter is zealotry -- seeking to punish a group through not following the "one true way".
Working vendor supported FOSS drivers are useful as the abilities to repair, improve, share and modify the drivers are all of considerable utility to the graphics card using community (even if not to one particular person in it). I do agree that the drivers should be at least servicable before anyone should buy a product. But servicable is all they need to be to be useful now.
--sabre86
Thanks for the kind words. What I find in general is that those who feel this is simply a matter of doctrinal rigidity are only interested in solving today's problem, without much vision toward what their lot might be tomorrow. Working to improve your own future is hardly zealotry.
Obviously it makes sense to decrease the degree to which we must be supplicants of a hardware vendor. That's even more true when the hardware vendor is in an essentially unchallenged duopoly. A vendor is working in our interest when they help us to free ourselves from the need to go to them to fix bugs, add functionality, and support our devices through software and hardware changes. When a vendor doesn't do this, we live constantly under the threat of withdrawl of support.
Rewarding vendors who do less will make it more certain that we'll get less in the future.
This all sounds eminently pragmatic to me.
Bruce Perens.
You'll find out how "imaginary" it is when your refusal to financially support the people doing the work causes them to stop doing it.
See, that's the huge fallacy with the argument that intellectual property has no owner, and therefore no financial value to any entity as it should be distributed without recompense: People generally do work because they are motivated. Things like houses, sending the kids to college, paying the water bill, buying the occasional gratuitous item -- if you take months of work and don't return something (and I'm not talking about a pat on the back), eventually, people will begin to ask themselves, "So... why did I do this again? I could have been working at McDonald's and paying off my house."
I will grant you it is easy to take work without recompense - particularly software, ideas, and performance recordings - especially since digital transfer has become so easy of itself; but I put it to you that your mindset is going to either kill the golden goose, or mutate it into something you're *really* not going to like. I don't think there's even a ghost of a chance you're going to see a transition into a Soviet-style "from each according to their ability, to each according to their need"; and that's the *only* type of society where your idea of "imaginary property" translates into something sensible: property that isn't so much imaginary, but owned equally by all.
I've fallen off your lawn, and I can't get up.
I don't care if something is open source or not unless that gives me a benefit.
The benefit is: If it crashes, you can do something about it.
You have the source. You can compile it yourself. If it doesn't work the way you'd like, you can change it.
With open source, you have many eyes looking at the code. If there is a subtle bug it will more easily be found by 10,000 people looking at it rather than 10 or 20.
That's your benefit right there.
Weaselmancer
rediculous.
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
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
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.
I am TheRaven on Soylent News
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)