Update On Open-Source AMD Fusion Llano Support

[phoronix]

Phoronix: Update On Open-Source AMD Fusion Llano Support

Last month when testing the AMD Radeon HD 6550D graphics as found on the AMD Fusion A8-3850 APU I mentioned the latest Git code (Linux kernel / Mesa / DDX) was broken for this Llano-generation APU while the proprietary Catalyst driver had "just worked" under Linux. Here's an update where the open-source driver support is now at today...

http://www.phoronix.com/vr.php?view=OTc4NQ

[edgar_wibeau]

Michael, as I wrote before in response to your previous Llano story, my A8-3850 integrated Radeon HD 6550D works well with the open Radeon driver. My story starts here. Using Ubuntu 11.04 I had exactly the same problems as you, could have made exactly the same screenshots. With 11.10 alpha (first steps with alpha 2) though, it works just fine. Even better with the git stuff from xorg-edgers. Did you do tests with Ubuntu 11.10?

Only problem: the KMS/kernel DRM doesn't seem to recognize the monitor connector correctly, I have a 1920x1200 TFT at the DVI port but radeon sees a ghost VGA monitor, activates that one and sets the resolution to 1024x768. I can correct this by fiddling with xrandr or better by adding "video=DVI-D-1:e video=VGA-1:d" to the kernel parameters. For details see my link above and following posts. If more details are needed, just say so, I'll try to provide them.

[Adarion]

"motherboard-specific"

Uuuuh. Sounds like quirks for every second mainboard are coming up. How I hate this. Why do they have to mess around with the chips? Nothing against some individuality but this "Extrawurst" that make things incompatible / not work without large workarounds really pisses me off. Or isn't it?

"Funny" thing is though that normally Linux driver devs find out about the hardware bugs because they try to do things as they are supposed to be done but then suddenly the HW freaks out cause it has a few non-public bugs here and there.

Well, but good to read that agd5f and team are up to these cuddly sweet things. Cause I am really thinking about spending my next free money on a Brazos or Llano machine, Laptop or HTPC. Okay, meanwhile I could also live with the fglrx.

By the way:
Is there anything ongoing in terms of the use of the UVD ASIC in the free drivers? Can it be used without causing the content mafia to scream when we just watch our correctly licensed BluRay movies on Linux?

[bridgman]

Uuuuh. Sounds like quirks for every second mainboard are coming up. How I hate this. Why do they have to mess around with the chips? Nothing against some individuality but this "Extrawurst" that make things incompatible / not work without large workarounds really pisses me off. Or isn't it?

I don't think we know yet. We don't have an easy way to keep track of how all the different hardware products are being designed; I think the usual process is along the lines of :

- implement initial code on hw #1
- same code works on hw #2
- change the code to work on hw #3, verify on hw #1 (you don't have #2)
- find that the code that works on #3 breaks #2
- get hw #4, change the code to work on #4, breaks #1 but works on #2, #3
- after seeing enough hardware figure out a way to program that works for almost all and only needs a small # of quirks for the outliers

Initial code is sometimes developed on prototype boards which turn out not to be anything like production boards. Same for BIOS.

Llano was one of those cases (where initial code was developed on prototype hardware). We used to do development primarily on production hardware but that doesn't work if we want to provide launch time support. Developing on prototype hardware is a lot more time-consuming because you more-or-less have to do the work twice.

Is there anything ongoing in terms of the use of the UVD ASIC in the free drivers? Can it be used without causing the content mafia to scream when we just watch our correctly licensed BluRay movies on Linux?

Still ongoing. Don't know the answer yet but it's something we really want to do.

Content mafia doesn't care in principle about you watching your correctly licensed BluRay disks on Linux, it's the requirement to publish driver source code and/or run on an open kernel that makes RE-ing easier, using the same hardware that plays protected content on other OSes, that makes them scream.

[smitty3268]

Content mafia doesn't care in principle about you watching your correctly licensed BluRay disks on Linux, it's the requirement to publish driver source code and/or run on an open kernel that makes RE-ing easier, using the same hardware that plays protected content on other OSes, that makes them scream.

You mean reverse engineering the security they use that has already been broken?

Anyway, regardless of what AMD does we need pipe-video support to mature a bit before anything else happens. AMD does have one guy who I think is working on adding h.264 shader decoding support into it - i'm not sure how that's going to work out legally speaking, with the patents and whatnot. It will be interesting to see exactly how much that helps compared to normal CPU decoding and UVD hardware decoding.

[bridgman]

You mean reverse engineering the security they use that has already been broken?

No, the other parts of the security stack, the ones that haven't been broken yet

[smitty3268]

No, the other parts of the security stack, the ones that haven't been broken yet

BTW, do you happen to know anything about the work going on with nouveau accelerating video? I know they are getting the actual vdpau chip rather than using shaders. Do you know if they've reverse engineered that? And will that lead the MPAA to ban them from selling all GPUs on Windows or anything? Because if i remember right that's what you said would happen if someone reverse engineered UVD. (I may be remembering that wrong)

[curaga]

It was RE'd, it's not like Nvidia suddenly decided to donate video unit specs. Other than that, I want to hear it too, bridgman