H.265/HEVC Main 10 Decode Support Added To Radeon UVD Code

[drSeehas]

... Stoney < Bristol.
Stoney is low-end, replacing Carrizo-L, ... Bristol is replacing Carrizo.
IIRC, Stoney has 1 "bulldozerish" module (2 integer cores, 1 FPU) and probably <= 4 GCN CUs (Compute Units). Carrizo has 2 modules and <= 8 CUs. ...

Why 2 different names for the same architecture?
Just to confuse me?
I don't get it :-(
There were always 2 core and 4 core versions of the same architecture with the same name (Richland, Kabini, Mullins/Beema, Kaveri).

So in simple words: Stoney Ridge is the 2 core version of the 4 core Bristol Ridge?
There will be no 4 core Stoney Ridge?
There are 4 core versions of Kabini, Mullins/Beema and Carrizo-L.

[bridgman]

There will be no 4 core Stoney Ridge?
There are 4 core versions of Kabini, Mullins/Beema and Carrizo-L.

2 strong oxen vs 4 chickens, at least that's the general idea. Single thread performance.

And yes I know the quote is "1024 chickens" but we don't have any 1024-core APUs yet.

[juno]

Why 2 different names for the same architecture?
Just to confuse me?
I don't get it :-(
There were always 2 core and 4 core versions of the same architecture with the same name (Richland, Kabini, Mullins/Beema, Kaveri).

So in simple words: Stoney Ridge is the 2 core version of the 4 core Bristol Ridge?
There will be no 4 core Stoney Ridge?
There are 4 core versions of Kabini, Mullins/Beema and Carrizo-L.

To keep it simple: yes.

long version: Mullins/Beema, C-L have much smaller cores (as I wrote 'tiny'). 2 cores are not twice as fast as 1 core in real-world usage, especially not 2 much smaller, slower cores.
No, there will not be any 4 core Stoney. That's what Bristol is there for.

"2-Core" Richland, Kabini, (Carrizo also exists) is basically the same die as the 4-core model with faulty/disabled hardware units. That is perfectly normal in semiconductor tech and is done to improve yields. Think of that: why throw away a 4-core chip with only 1 faulty core? you can still sell it cheaper as 2 or 3 (AMD used to) core.
Remember there is always a partial-disabled/faulty GPU (XT is the full version, PRO the disabled, in most cases easy to see in AMD's marketing names on the trailing "X", e.g. 290(X), Fury(X), 380(X), ...) <- that's basically for the same reason. Sometimes IHVs happen to disable their dies in a very dumb way, to improve yields and therefor margin even more - that's when you get some 3.5+0.5 GiB VRAM card.
But back to APUs... manufacturing a big die is still more expensive and it is obviously still bigger. So you can't just disable half of the big die and fit it in a very small form factor device - that's what Stoney is there for.

plus, we don't know yet if BR is really a new die compared to Carrizo. Maybe it's the same, in which case you don't have the same "architecture", because Stoney has the new UVD this news is about and Carrizo does not.

[bridgman]

The other point is that as fab processes mature and yields improve you simply don't get the accumulation of parts that need to have blocks disabled. Making big-die parts and selling them as small-die parts only makes sense if harvest parts happen anyways despite your best efforts to get yields up.

[azari]

Imo it's not that clear when you have "radeon" and "amdgpu" listed both at kernel and at DDX level.

X11 kind of confuses the situation; it's a lot easier to understand in Wayland, since in most Wayland compositors, they eliminate all the hardware-specific drivers (which is what DDX is in X11), and they just run on top of OpenGL, and thus all the hardware-specific details are limited to the kernel and mesa in a post-wayland world.

From my limited understanding, what I've gathered is that it's been difficult to do X11's drawing primitives and stuff on top of a higher level abstraction like OpenGL, and so historically they've needed hardware-specific DDX drivers that interface directly with the kernel drivers. However, this is what GLAMOR is trying to change I think.

Vulkan I think is also going to make things a bit clearer to understand for newer hardware, because it just sits directly on top of the kernel drivers, and does not go through Mesa. If amdgpu gets stable GCN1.0 support, it will also be easier to understand as there will then be a direct mapping of the kernel amdgpu driver to radeonsi in mesa, with the radeon kernel driver and all the other mesa backends being for pre-GCN hardware.

bridgman, btw, would AMD implement VP9 HW decoding? Who gives a fuck about H.265, if whole youtube HQ content is VP9 at their best resolutions/quality? At 2K/4K it could get quite taxing on CPU and these days I can't imagine HTPC-like use cases without youtube support.

Maybe some vendors are taking a wait-and-see approach regarding the royalty-free codecs, due to the announced collaboration between Google, Mozilla, Microsoft, Amazon, Cisco, Intel, and Netflix on a new royalty-free codec to beat HEVC (Alliance for Open Media). This new codec is supposed to be released sometime in 2017, so why add hardware support for something that may become completely obsolete in a year's time? Google is a part of this alliance, and they will no doubt be one of the first to switch YouTube to using it the moment it's released.

As for HEVC, I'm not sure why they're supporting it, perhaps because it has a lot of marketing power behind it, so they're adding it even though people may end up not even using it in the real world, because it increases sales from people who aren't aware that it probably won't be on top for very long. We know Google won't want to support HEVC on YouTube, but Twitch will also probably not support it, because Amazon owns them and they are part of the group making the new codec.

[SystemCrasher]

Maybe some vendors are taking a wait-and-see approach regarding the royalty-free codecs, due to the announced collaboration between Google, Mozilla, Microsoft, Amazon, Cisco, Intel, and Netflix on a new royalty-free codec to beat HEVC

Still, the facts are:
1) Even Microsoft acknowledged VP9 is good thing and they are going to implement it. Mozilla and Chrome are using it for ages. Sure, if they'll wait 10 years, it could be just as much point to implement it as doing HW acceleration of MPEG 1 these days, where mostly nobody cares about it. But it could be just way too late at this point.
2) World is not going to stop and wait. New codecs will appear, etc. So one can end up waiting forever.
3) Silicon estate of VP9 decoder and even encoder is okay even for small mobile SoCs these days, so there is very little excuse large GPUs do not support it here and now.

This new codec is supposed to be released sometime in 2017, so why add hardware support for something that may become completely obsolete in a year's time?

To the date hardware supports clearly outdated MPEG1/2, old MP4s like xvid, H.264 despite of H.265 existence and so on. Failing to support VP9? Erm, maybe they should better wait with H.265 adoption for 5 years or so. After all, it costs us, the users some royalties, unlike VP9, increasing hardware prices. But I have no even slightest fuck where I'm supposed to get H.265 content. At the end of day, it seems nobody uses H.265 online and browsers are entirely lack support of it, due to woeful licensing terms.

Google is a part of this alliance, and they will no doubt be one of the first to switch YouTube to using it the moment it's released.

AfAIK, it mostly going to be mostly based on VP9/10 because it is best thing which exists and works to the date. Either way, we have full youtube of VP9 content here and now, and what would happen 1.5 years later is another story. Sorry, but 1.5 years from now they can just design new UVD/VCE blocks and release them as part of new GPU ICs.

As for HEVC, I'm not sure why they're supporting it, perhaps because it has a lot of marketing power behind it

This seems to be purest marketing BS, probably by MPEG LA and few other royalty racketeers. IMHO, helping other entities to conduct racket is a crime, not a feature at all.

[Kano]

Interestingly Amazon added MPEG2 for Mediacodec with FireOS 5, it was not available before. Also it is still used for SD TV stations and a some BluRay. If the CPU is slow you gain much with native MPEG2 support. HEVC Main 10 @ 4k is the new standard for 4k TV stations, would be stupid not to implement it. Also used for Ultra Bluray.