UVD/hw acceleration If, when?

[gbeauche]

Thanks bridgman

So to sum up, please correct me if I'm wrong:
1. There are no plans to use UVD in open source radeon stack, probably due to legal issues.
2. There are other priorities to be fulfilled before HW accel is even considered by AMD devs.
3. Not all of h.264 will be decoded on the GPU (as in UVD), but rather the easily parralelizable parts like motion compensation etc. Correct me if I'm wrong, but this would still require a decent processor (circa 2.2GHz?) to do the serial (bytestream?) operations with high bitrate streams (1080p?)

I don't have Linux media players that support only MC for H.264 but for MPEG-2, I do have some clips that are hard to decode: 40% CPU of dual core Athlon 64 @ 2.7 GHz + IDCT through shaders (fglrx).

If you want something realistic for the next two years, the only solutions are Intel and NVIDIA. 2 years is the estimated timeline to fix current bugs in fglrx, and 2 years might be the time needed to have decent OSS solutions(?). I don't want to break your hopes, just be objective and realistic. And, indeed, within the next two years, we will have interesting CPUs with improved SIMD cores (AVX extensions) that could help too, at least for other codecs like H.265. And yes, during 2 years, other HW vendors would evolve too.

[bridgman]

Main concern here is that you're taking my *guesses* about what the driver dev community (including mostly non-AMD devs) is likely to end up doing, and trying to evolve it into a precise *AMD* plan.

1. There are no plans to use UVD in open source radeon stack, probably due to legal issues.

There are no plans today, ie UVD was not part of the original open source driver plan and we have not yet been able to create a plan which we feel is sufficiently safe (from a technical POV) to fulfill our legal and business obligations.

In a very loose sense, the criteria could be summarized as "don't become a weak link in the DRM chain".

2. There are other priorities to be fulfilled before HW accel is even considered by AMD devs.

Yes, for both AMD and community devs.

3. Not all of h.264 will be decoded on the GPU (as in UVD), but rather the easily parralelizable parts like motion compensation etc. Correct me if I'm wrong, but this would still require a decent processor (circa 2.2GHz?) to do the serial (bytestream?) operations with high bitrate streams (1080p?)

Possibly; I haven't looked at a recent analysis of where CPU time goes with contemporary clips and decoders. What I'm saying is that I think it's likely you will see some shader-based HW acceleration but given the rate of industry progress, the level of developer interest, and the typical GPU/CPU mix of existing hardware I don't think it's likely to go much further than MC before running into throughput limitations on the low-end GPUs which typically get paired with low-end CPUs.

4. The HW accel is planned to be done on top of Gallium for easy portability accross gfx cores at the expense of more CPU power requirements, or is to be done in native ATI shader code for more performance at the expense of portability.

Yeah, I think those are the most likely options.

[bridgman]

"Possibly" in the previous response to #3 should read "Probably".

I don't have Linux media players that support only MC for H.264 but for MPEG-2, I do have some clips that are hard to decode: 40% CPU of dual core Athlon 64 @ 2.7 GHz + IDCT through shaders (fglrx).

FYI I believe the fglrx driver is using the legacy IDCT hardware in all but the most recent parts rather than running IDCT on shaders.

[Neuro]

I don't have Linux media players that support only MC for H.264 but for MPEG-2, I do have some clips that are hard to decode: 40% CPU of dual core Athlon 64 @ 2.7 GHz + IDCT through shaders (fglrx).

If you want something realistic for the next two years, the only solutions are Intel and NVIDIA. 2 years is the estimated timeline to fix current bugs in fglrx, and 2 years might be the time needed to have decent OSS solutions(?). I don't want to break your hopes, just be objective and realistic. And, indeed, within the next two years, we will have interesting CPUs with improved SIMD cores (AVX extensions) that could help too, at least for other codecs like H.265. And yes, during 2 years, other HW vendors would evolve too.

It just happens that I've got a notebook here with an Ati Radeon 3450. The notebook is sufficiently powerful for what I'll do in the next two years or so, and I don't plan to throw it away after that either

So I'm interested in what I can do on hardware that I own. And that's exactly why I'm posing the question. I'm fairly pragmatic and I don't mind using NVIDIA for building HTPCs

[gbeauche]

FYI I believe the fglrx driver is using the legacy IDCT hardware in all but the most recent parts rather than running IDCT on shaders.

Ah, OK. It was brought to my attention that UVD only implemented H.264 and VC-1 codecs at VLD level to match certain initial application requirements. And that it didn't include MPEG-2 @ VLD for that reason (space?) thus I assumed MPEG-2 IDCT was done by the usual GPU unit.

[droidhacker]

low-end GPUs which typically get paired with low-end CPUs.

I think that the BIG thing that needs to be remembered here is that a GPU is much more easily upgraded than a CPU. A graphics card is literally a drop-in part whereas a CPU upgrade will typically ALSO require a mainboard and RAM since any particular low-end/older CPU will probably have a socket configuration for which there are no new chips available. For example, try finding a new AMD cpu for socket 939, or even worse, 754.

On the other hand, what would really help out this whole issue would be the availability of affordable DEDICATED video decoders, i.e. drop-in PCI-e X1 video decoder cards. I think broadcom makes some suitable hardware for MOBILE devices, but pair that with the necessary socket adapter and you're over any kind of sane budget. All this integrated stuff is really a pain. I see the practical value of it for things like CELLPHONES, but not for stationary devices -- there they are simply inflexible.

[curaga]

How many 2/4-socket server boards still have Ati Rages? Or other low-end gpu, for the matter.

[bridgman]

I think that the BIG thing that needs to be remembered here is that a GPU is much more easily upgraded than a CPU. A graphics card is literally a drop-in part whereas a CPU upgrade will typically ALSO require a mainboard and RAM since any particular low-end/older CPU will probably have a socket configuration for which there are no new chips available.

Yes and no - most of the slow CPU / small GPU combinations seem to be in laptops, where neither component is easily upgradeable.

[Jimbo]

The main risk to shader-based decoding IMO is multi-thread decoders maturing and fast CPUs becoming sufficiently cheap and power-efficient that the community loses interest in GPU decode before it gets fully implemented.

Good point!! all future CPU are going to be multi-core, and more cores every year. Even 4W atoms are multicore. I am pretty impressed with ffmep-mt performance:

- Atom 8W cpu can decode 720p video.
- Core 2 duo 2,2Mhz, 2 cores, 40W, can decode 1080p 40Mbps video.

What could achieve an 8 - 12 cores opteron?

[HokTar]

What could achieve an 8 - 12 cores opteron?

You are shooting a bird with a canon, don't you think?