AMD Overhauls Open-Source Linux Driver

An anonymous reader writes "AMD's open-source developer has posted an incredible set of 165 patches against the Linux kernel that provide support for a few major features to their Linux graphics driver. Namely, the open-source Radeon Linux driver now supports dynamic power management on hardware going back to the Radeon HD 2000 (R600) generation. The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been a major limiting factor for open-source AMD users where laptops have been warm and there is diminished battery power. The patches also provide basic support for the AMD Radeon HD 8000 'Sea Islands' graphics processors on their open-source Linux driver."

Comments

Yay AMD

[Noishe]

This is a great step in the right direction. Hopefully it's not the last step.

Re:Yay AMD

[fuzzyfuzzyfungus]

This is a great step in the right direction. Hopefully it's not the last step.

AMD's penurious financials do make me nervous; but their strategic change in favor of *gasp* actually working to integrate support for their product into the kernel development process proper seems to be sincere and ongoing. Slower moving than one would like; but since they began their course-change, they've kept it up.

Re:Yay AMD

[0123456]

How could you be nervous about AMD? They're in every single next generation console system.

And what do you think profit margins are for console components?

Good guys AMD

[Reliable Windmill]

I'm excited about getting the upcoming Kaveri. APUs are the way to go unless you have needs that call for huge CPU or GPU power, and I think AMD is definitely leading the innovation here. It's a nice bonus if I will be able to run Linux with good graphics acceleration as well.

Re:Good guys AMD

[jkflying]

Personally, I'm excited about HUMA and what it will mean for scientific computing. The second half of this year will be exciting!

Re:Good guys AMD

[Belial6]

I have to agree. My son's laptop with an A10 processor beats both mine and my wife's laptops with i5. They all cost about the same amount. My laptop is fine for most tasks, but fails at gaming. My son's A10 handles every game he has tried without problem. There may be some that won't run well on it, but until we find one that doesn't, anything more would be wasted money.

Still not Stallman-approved.

[snarfies]

Per http://stallman.org/to-4chan.html:

"Regarding graphics accelerators for PCs, ATI mostly cooperates with the free software movement, while nVidia is totally hostile. ATI has released free drivers.

However, the ATI drivers use nonfree microcode blobs, whereas most of nVidia's products (excepting the most recent ones) work ok with Nouveau, which is entirely free and has no blobs.

Thus, paradoxically, if you want to be free you need to get a not-very-recent nVidia accelerator.

I wish ATI would free this microcode, or put it in ROM, so that we could endorse its products and stop preferring the products of a company that is no friend of ours."

This sort of thing gets discussed quite a bit on 4chan's technolo/g/y board. Also, installing Gentoo.

Re:Still not Stallman-approved.

[fuzzyfuzzyfungus]

Blobs are definitely not ideal; but I've never really understood the distinction between people who put them in ROM and people who require them to be loaded at initialization time(as long as they aren't assholes about redistribution: if Distro X is legally unable to distribute firmware.bin and I have to go to your site, download the Windows driver, and then chop it open to get firmware.bin, just to get an unaltered copy of your firmware to run with your device, I'm going to be pissed).

Both approaches involve exactly the same binary firmware blob, one just stores it on comparatively expensive, board-space-consuming, flash ROM and one stores it on system mass storage.

Firmware that is open is better than either; but closed firmware that is handled behind the curtain on the card seems no better than closed firmware that is supplied to the card during startup(again, assuming proper redistribution terms and proper driver support for that aspect of initializing the device).

Re:Still not Stallman-approved.

[Bill, Shooter of Bul]

I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software. Same code, just different home.

Re:Still not Stallman-approved.

[TubeSteak]

I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software.

Licensing and distribution.

Anything that's in hardware has already dealt with the issues of licensing and distribution.
Closed source software represents and entirely different beast for free software distribution.

Re:Still not Stallman-approved.

[icebike]

The entire point of firmware being upgradable is that it is... well... upgradable. Not only that, but different versions of firmware may be required for different versions of software. This way it is much easier to ensure compatibility, because the driver has the firmware baked into it.

If it were firmware, I would be in agreement.

The objection to binary blobs, that are simply loaded into the device as firmware is sort of short sighted,
in that it punishes vendors that actually plan in a method of upgrading their products with new firmware.

But by and large, that isn't the issue here.
Far to many of these blobs are loaded loaded into main memory and run as a process under the operating system,
free to do just about anything.

If blobs were ONLY firmware, they could run ONLY on the device, and could be loaded once at installation time.
Very few fall into this category. (Some wifi chips do load this way upon every boot).

Far too many remain running in main memory.

Re:Still not Stallman-approved.

[LourensV]

I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software. Same code, just different home.

Back in the days of the Open Graphics Project (since defunct, although Timothy N. Miller is still working in this area and the mailing list is still active for those interested in the subject), we had several discussions about the borders between Free software, open firmware, and open hardware.

As I understood the FSF's position at that time, the point is that if the firmware is stored on the host, it can be changed, and frequently is (i.e. firmware updates). Typically, the manufacturer has some sort of assembler/compiler tool to convert firmware written in a slightly higher level language to a binary that is loaded into the hardware, which then contains some simplistic CPU to run it (that's how OGD1 worked anyway). So, the firmware is really just specialised software, and for the whole thing to be Free, you should have access to the complete corresponding source code, plus the tools to compile it, or at least a description of the bitstream format so you can create those. This last part is then an instance of the general rule that for hardware to be Free software-friendly, all its programming interfaces should be completely documented.

If the code is put into ROM, it cannot be changed without physically changing the hardware (e.g. desoldering the chip and putting in another one). At that point, the FSF considers it immutable, and therefore not having the firmware source code doesn't restrict the user's freedom to change the firmware, since they don't have any anyway. The consequences are a bit funny in practice, as you noted, but it is (as always with the FSF) a very consistent position.

We (of the OGP-related Open Hardware Foundation, now also defunct; the whole thing was just a bit too ambitious and too far ahead of its time) argued that since hardware can be changed (i.e. you can desolder and replace that ROM), keeping the design a secret restricts the users freedom just as well. So, we should have open hardware, which would be completely (not just programming interfaces, but the whole design) documented and can therefore be changed/extended/repaired/parts-reused by the user. The FSF wasn't hostile to that idea, but considered it beyond their scope. Of course, any open hardware would automatically also be Free software-friendly.

I tend to agree that in practice, especially if there are no firmware updates forthcoming but it's just a cost-savings measure, loading the code from the host rather than from a ROM is a marginal issue. Strictly speaking though, I do think that the FSF have a point.

Re:Still not Stallman-approved.

[Boltronics]

Yes, this is my opinion exactly. I recently blogged about this exact issue, and why I think the FSF, RMS, Trisquel, etc. all treat it differently - and I don't think it's a good enough reason.

https://systemsaviour.com/2013/06/16/why-i-will-not-back-fsfs-guidelines-for-free-software-distributions/

I'll point out for Slasdot readers that, in the case of the radeon driver, it loads microcode into the card - not a huge firmware blob. The FSF just refers to microcode as firmware, so does not distinguish between them. The microcode is between 2K and 31K, depending on the model of the device. If running Debian GNU/Linux with the firmware-linux-nonfree package installed, these microcode files should be located under /lib/firmware/radeon.

Thank God.

[intermodal]

My laptop ran ridiculously hot on the open-source until I got the closed-source drivers to install properly. Let's hope the fix means default installs of Ubuntu won't melt your igloo.

Side effect of console design wins?

[JDG1980]

I can't help but wonder if this is related to AMD's recent console design wins, especially PS4. Up until now, there hasn't really been a strong business case for putting a lot of effort into Unix-based video drivers. But since PS4 runs on FreeBSD and uses OpenGL as its API layer, a lot of the effort that AMD put into the drivers there can probably be ported over to the Linux drivers without much trouble. The PS4 and Xbone GPUs both use AMD's standard Graphics Core Next (GCN) architecture.

Re:Side effect of console design wins?

[gman003]

You don't really know what a development kit is, do you?

A devkit is not an SDK. It's the same hardware and software as the retail product, but with additions/modifications that enable debugging (adding debugging ports, using libraries with debug symbols, etc). They also get the ability to run "unlicensed" software, since you can't go to Sony/Microsoft/Nintendo every time you compile in order to have it certified. And, finally, early devkits may not have the final case/board, since launch titles need to start development well before the case or even motherboard are finished (famously, the early Xbox 360 devkits used Power Mac G5 cases and motherboards).

So if the devkit is running a FreeBSD kernel, the final product will be running a slightly different version of the same kernel.

Re:AMD needs to do this 1000% more

[jedidiah]

Nvidia is only worse in some sort of GPL zealot fantasy land. Out in the real world, it's not so bad actually. They provide the support. They just don't provide it in the precise manner that a noisy minority wants.

AMD can start by displacing 6 year old ION kit.

Most likely pulled from your butt.

[Anonymous Coward]

NVidia tried that and made the mistake of saying who the IP that was the roadblock was: Sun. Sun Microsystems said "There is nothing that they have of ours that we would refuse to have open sourced". NVidia's response was to clam up and let the fanbois repeat the claim for ever more.

Re:Why not open source it period?

[0123456]

Maybe there's a boat load of trade secrets in the closed source drivers, but I'd imagine that this is a perfect area for patents to be used against competitors.

You have that backwards. If their drivers are inadvertantly violating a patent owned by Joe's Patent Trolls, Inc, then making the drivers open source makes that violation much easier to spot.

Patents are a huge disincentive to releasing open source drivers. Another issue the company I worked for had was hardware bugs, because having to put bizarre workarounds in closed source drivers was no big deal, but a bit embarrassing in open source.

AMD Financials Summary

[Anonymous Coward]

$2B in debt, $1B cash, lost $600M last year, sales dropped 30% last year. They have no assets (spun off their manufacturing facilities). If the next gen consoles do not sell well because of casual / tablet gaming and potential Apple TV games, AMD will be bankrupt in one year and shuttering in two. Spending money on open source drivers is a long term investment - it's not going to get them an additional $600M in revenue next year (>2M additional graphics cards or >5M systemic wins) when PC sales are on the decline.

Re:AMD Financials Summary

[tyrione]

$2B in debt, $1B cash, lost $600M last year, sales dropped 30% last year. They have no assets (spun off their manufacturing facilities). If the next gen consoles do not sell well because of casual / tablet gaming and potential Apple TV games, AMD will be bankrupt in one year and shuttering in two. Spending money on open source drivers is a long term investment - it's not going to get them an additional $600M in revenue next year (>2M additional graphics cards or >5M systemic wins) when PC sales are on the decline.

Right and within 1 year the number of GPGPUs sold via their custom APUs inside Consoles with be 6:1 to 10:1 of your sales. They are in the new Wii, PS4 and XBox. They're expanding their small-to-mid-tier server footprint [beginning to own that space] and with more and more laptops using AMD APUs will begin to own that space. Their partnership with ARM will make them an attractive provider for future Smart TVs, and other embedded products not even yet projected out. AMD is going to be in the black very shortly.

http://www.istockanalyst.com/finance/story/6474155/3-v-checking-fbr-capital-markets-5-50-advanced-micro-devices-inc-amd-price-target ``Later in the report, Rolland added, `Whereas four months ago many investors were questioning AMD as an ongoing entity, today, we believe financial stability has been secured by next-gen gaming APU wins, with potential upside driven by new initiatives like SeaMicro. While AMD's recent woes remain fresh in mind, the business looks as though it has stabilized for now, and cash levels should remain sufficient for the near future.'

Obviously, investors are attracted by the possibility of a 35.8% return within a 12 month timeframe. If Rolland is correct, that's sort of like having your own ATM. Let's examine Advanced Micro Devices' five-year history for price-to-book (P/B), price-to-sales (P/S), and trailing price-to-earnings (P/E) to see if the analyst's price-tag is realistic.

While we have this AMD conversation, the street values the company at 6.98 times its book value; whereas, competitor Intel Corporation (INTC) trades with a P/B value of 2.34. To get to $5.50 based on the current book value of $0.58 per share, AMD would trade at 9.48 times book, well above the five year average of 4.78, but below the max of 17.06.

Since Wall Street expects AMD to lose $0.25 per share in 2013, we'll have to work with 2014's consensus profit estimate of $0.04 for our P/E analysis. A price-target of $5.50 requires a P/E of 137.5; whew, feeling a little light headed from the high altitude. How about you? It is dizzying as AMD's highest P/E in the last five-years has been 22.07. Five-fifty seems to be a little out-of-reach based on P/E. "

HUMA

[Anonymous Coward]

Hybrid Unified Memory Access.

Basically both your CPUs and GPUs having access to the same memory space without needing to 'swap' via apertures or anything else. It's currently intended for the gpu in APU packages, but I believe they've stated one of the next gen GPU platforms (HD9xxx?) is going to support it as well.

Re:AMD needs to do this 1000% more

[drinkypoo]

Then again, AMD's Linux drivers actually work, while nVidia's do not.

Then again, you have that exactly backwards.

Good, but still a long way to go

[xiando]

I've got a HD3300 IGP and that works alright with the open source driver. Not good, but alright. Then I bought a HD7850 and tried using the latest open source drivers. By latest I mean MESA snapsot from 20130619 and all the latest pieces. It is utterly broken and useless. Scrolling in applications cause artifacts. Starting some applications (like LibreOffice) just makes X hang. There is no usable open source drivers for the latest AMD cards. Yes there is something available, but it's a broken joke you can't actually use.

It is possible to use the open source driver to have one monitor on the HD3300 IGP and two monitors on the HD7850 without accelration on any of the monitors. Try the same setup with accelration and their driver segfaults.

I basically bought a HD7850 because AMD claims there's a open source driver for it. When you try it you'll find that there is no such thing as a functioning open source driver for this card and cards in this family.

The new kernel patches are probably a step in the right direction, but it won't help with the latest cards. AMD developers have in their wizdom decided to provide no 2D driver at all, instead they rely on 3D for 2D using MESA and "glamor". glamor is a buggy joke at this point and it will probably take years before that changes. I wish I could point to AMD and say "they've got great open source support" but the truth is that it's crappy at best. Intel is the only alternative if you want working free software drivers as of now.

Re:Good, but still a long way to go

[ak3ldama]

Does intel make an HD7850 counterpart? Your comment lacks a lot of perspective.

Full prick mode: Also I wouldn't say that they claim there's a open source driver for it. It is not like they market it that way with a big sticker on the box. There are a lot of missing features yet for the whole south islands series and there are a lot of bugs. This is /. you should know these things.

Nice mode again: It is one thing that your card is a year old, but you should have bought something older or done some more research. I went full ghetto (in early 2010) and bought a 4670 and have had no problems with the setup. And it was cheap, the kind of cheap where you don't care that you are using a potentially slower open source driver.