Page 8 of 29 FirstFirst ... 67891018 ... LastLast
Results 71 to 80 of 283

Thread: AMD Releases Open-Source UVD Video Support

  1. #71
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by brent View Post
    No - APUs are definitely a lot slower. "Very close to the blobs" is very much a hyperbole, and only true with certain GPUs and few 3D applications. But on APUs the gap is even bigger, compared to desktop GPUs. The most serious problem is that APUs can't be reclocked to their full clock, and so by means of clock speed they are limited to ~40% of their actual performance level.
    That is complete and utter nonsense.

  2. #72
    Join Date
    Jan 2010
    Posts
    364

    Default

    Quote Originally Posted by droidhacker View Post
    That is complete and utter nonsense.
    Nice arguments you got there.

    APUs can only use a low default clock because thermal management isn't implemented and just ignoring that could possibly overheat the poor APU. I'm pretty sure bridgman will confirm that for you. IIRC he (or Alex?) also noted that in some post on these forums.

    Edit:
    For instance, the E450 APU has multiple power states: 173 MHz, 200 MHz (default), 275 MHz, 504 MHz and 600 MHz (boost state). But the radeon open source driver will not go over the default clock of 200 MHz to make sure the APU will never exceed thermal limits. That's just 30% of the maximum clock (or 40% if you don't count the boost state)!

    The relevant part of the driver is right here:
    http://lxr.free-electrons.com/source...m.c?v=3.8#L167
    Last edited by brent; 04-03-2013 at 10:21 AM.

  3. #73
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    513

    Default

    Quote Originally Posted by brent View Post
    Nice arguments you got there.

    APUs can only use a low default clock because thermal management isn't implemented and just ignoring that could possibly overheat the poor APU. I'm pretty sure bridgman will confirm that for you. IIRC he (or Alex?) also noted that in some post on these forums.
    As an APU user I would like confirmation too.

  4. #74
    Join Date
    Apr 2011
    Posts
    330

    Default

    Quote Originally Posted by droidhacker View Post
    At least not once the koolaid has been consumed, as you obviously have.


    Why would anybody possibly want to use catalyst??? Radeon performs close (and in some cases *ahead*) of catalyst, and supports everything that catalyst does.


    Are you possibly confusing AMD with nvidia??? I choose AMD ***because of open source***.


    Ok, so you want to REALLY MURDERFY intel then? LOL.


    That would be helpful, but you can control power consumption quite easily already.


    ... uh, right. That poor 3D performance that is already WAY WAY better than intel, and "right up there" with nvidia blobs?


    AMD is basically ahead of intel in ALL of your "wants".


    If you are an opensource supporter, buy AMD. AMD open source stuff actually works. Too bad you drank the koolaid.



    The first that matters is Wine behavior. There is not a reason to buy an extra GPU for non gaming purposes, i will prefer a cheap integrated. To this field Nvidia has the first place with a quality closed driver, wile AMD has the fourth place, after Intel with open driver and probably even Imagination(Atom). So if you are a hardcore gamer you need extreme single thread performance(Intel AVX or at least SSE4.2, OC) and an Nvidia_64bit GPU(even a small one 96-384 cores). If you not, you will buy from a contributor to MESA, for now there is only Intel. There is not a single reason for anything else. And a safe conclusion is: The first GPU vendor that will support native HLSL compilers with their Linux driver, wins probably for ever. They must give as the power to run MS-D3D via Wine without GLSL translation, natively. This means that they must give an HLSL compiler target back-end with the Linux driver, plus an recognition front-end for HLSL if needed. If they don't we must start to thing our own solution before an open HLSL compiler: We can extract the missing driver parts from the Windows drivers via Winetricks, and let MS-D3D see them (with some small Wine code).

  5. #75
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by artivision View Post
    The first that matters is Wine behavior. There is not a reason to buy an extra GPU for non gaming purposes, i will prefer a cheap integrated. To this field Nvidia has the first place with a quality closed driver, wile AMD has the fourth place, after Intel with open driver and probably even Imagination(Atom). So if you are a hardcore gamer you need extreme single thread performance(Intel AVX or at least SSE4.2, OC) and an Nvidia_64bit GPU(even a small one 96-384 cores). If you not, you will buy from a contributor to MESA, for now there is only Intel. There is not a single reason for anything else. And a safe conclusion is: The first GPU vendor that will support native HLSL compilers with their Linux driver, wins probably for ever. They must give as the power to run MS-D3D via Wine without GLSL translation, natively. This means that they must give an HLSL compiler target back-end with the Linux driver, plus an recognition front-end for HLSL if needed. If they don't we must start to thing our own solution before an open HLSL compiler: We can extract the missing driver parts from the Windows drivers via Winetricks, and let MS-D3D see them (with some small Wine code).
    Wine doesn't even work. Certainly isn't worth even one second's consideration.

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

    Default

    Quote Originally Posted by brent View Post
    But on APUs the gap is even bigger, compared to desktop GPUs. The most serious problem is that APUs can't be reclocked to their full clock, and so by means of clock speed they are limited to ~40% of their actual performance level.
    I believe brent is correct. Clock-for-clock the open source drivers run decently fast on APUs, but IIRC the clocks are left at default which is pretty low on most systems. You can manually bump the clocks but without thermal management we're not recommending it right now.

  7. #77
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote Originally Posted by droidhacker View Post
    That's absurd. The open source drivers are very close to the blobs. You're way behind the times.
    discrete AMD card has less than 50% frame rate of Intel GPU with open source drivers
    in Xonotic 0.6 Low
    Radeon 4830 - 69 fps
    Intel HD 4000 - 163 fps

    http://www.phoronix.com/scan.php?pag...sa91_ivb&num=5
    http://www.phoronix.com/scan.php?pag...ar_r4830&num=5
    Last edited by JS987; 04-03-2013 at 10:45 AM.

  8. #78
    Join Date
    Jan 2010
    Posts
    364

    Default

    Yeah, I removed the check that limits the clock, but obviously that's not safe. It shouldn't be that hard to implement simple thermal management, I guess. Unless I am missing something, you just have to reduce the clock when it gets too hot.

    AMD guys, please consider documenting at least the bit of the hardware needed for this, as quickly as possible, if it is possible. It's a real showstopper that all mobile APUs have abysmal performance. :/

  9. #79
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    We actually expected the next round of power management IP to get approved for release before UVD, but it didn't work out that way.

  10. #80
    Join Date
    Jan 2010
    Posts
    364

    Default

    Quote Originally Posted by bridgman View Post
    We actually expected the next round of power management IP to get approved for release before UVD, but it didn't work out that way.
    Good luck, the unexpected UVD code drop raised some hope that this might be actually happening some day.

    However, I still think something is really broken (and frustrating for all involved) if these processes take so long and have unpredictable outcome.

Posting Permissions

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