Results 1 to 8 of 8

Thread: Update On Open-Source AMD Fusion Llano Support

  1. #1
    Join Date
    Jan 2007
    Posts
    14,357

    Default Update On Open-Source AMD Fusion Llano Support

    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

  2. #2
    Join Date
    Mar 2008
    Posts
    71

    Default

    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.

  3. #3
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    769

    Default

    Quote Originally Posted by Michael/agd5f in the article
    "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?

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by Adarion View Post
    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.

    Quote Originally Posted by Adarion View Post
    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.
    Last edited by bridgman; 08-14-2011 at 11:18 AM.

  5. #5
    Join Date
    Oct 2008
    Posts
    3,036

    Default

    Quote Originally Posted by bridgman View Post
    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.

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by smitty3268 View Post
    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

  7. #7
    Join Date
    Oct 2008
    Posts
    3,036

    Default

    Quote Originally Posted by bridgman View Post
    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)

  8. #8
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,993

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •