AMD Releases Open-Source UVD Video Support

[droidhacker]

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.

[brent]

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/drivers/gpu/drm/radeon/radeon_pm.c?v=3.8#L167

[Drago]

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.

[artivision]

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).

[droidhacker]

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.

[bridgman]

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.

[JS987]

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?page=article&item=intel_mesa91_ivb&num=5

http://www.phoronix.com/scan.php?page=article&item=amd_lucidrar_r4830&num=5

[brent]

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. :/

[bridgman]

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.

[brent]

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.