UVD/hw acceleration If, when?

[Neuro]

Hi,

I moved from FGLRX to the open source stack... and honestly, I guess I'm never going back. Colour-correct XV without flickering, smooth composite for KWin and KMS...

As I don't do any gaming, I really have no need for OpenGL > 2.0. I'm more insterested in hardware acceleration of h.264 and VC1 video. I've already tried out the FGLRX solution (9.10 and 9.12 hotfix) on my Radeon HD 3450 (which, odly enough, reports UVD2) and it worked fine. I liked being able to play _some_ 1080p videos smoothly.. However, the implementation is far from complete, most clips have blocky video, most have incorrect colours and most of all: the bloody flickering of FGLRX's mplayer GL output kills the whole experience.

So, will UVD support in the open-source stack ever happen? I've heard that there is some legal stuff to sort out: i.e. whether or not releasing specs for UVD will but AMD's DRM tech at risk.

I'd like to ask the following questions to the AMD staff which roam this forum:
1. What is the status of the legal review? Has it already started?
2. If the legal review clears UVD docs to release, what technical requirements will need to be implemented first before UVD is implemented in the driver with a VA-API/VD-PAU/XVBA/whatever-api interface? How much work will that be, in other word: how long would it take for someone skillfull to implement these specs (any guesswork would do )?
3. If the legal review doesn't clear UVD (which would be a terrible shame), are there any plans of implementing h.264/VC1 acceleration through shaders? What would be the technical requirements (I guess working radeon galium backend) and how much work would that be?

[rohcQaH]

Hi,

UVD for the 3xxx is unlikely due to the DRM issue. AMD makes an effort to decouple DRM from UVD, but that cannot be done on finished architectures, it's something for their new developments. Remember that GPU architectures take a few years from planning to release.

But UVD only decodes parts of the video, a lot is decoded using shaders. Shader docs are available. Video acceleration for 3xxx could have been done for months or years, but nobody stepped up to do it, and ATI themselves won't do it (yet?) because they have different priorities.

Gallium3D could be the answer, a generic state tracker for video decoding would be usable by all G3D drivers, not just ATI, so it's much more likely for someone to step up and do it (and IIRC some work has already been done).
Noone really knows (or tells) when G3D will be ready for end-users though or when a r500 g3d driver will be available.
It's the best bet for GPU accelerated video, but without an ETA.


For now, there are multithreading-patches for some video software. If you're running a dual-core, try those. From what I've heard, many 1080p videos will run smoothly on a halfway decent dual-core CPU.

[droidhacker]

Dual core is a must.
ffmpeg-mt is sortof-ok-ish, but it still a bit lacking.
CoreAVC, which is a windoze software decoder, works fine. There are patches for mplayer to use coreavc, and there is a wrapper for running coreavc on linux.

[Neuro]

Dual core is a must.
ffmpeg-mt is sortof-ok-ish, but it still a bit lacking.
CoreAVC, which is a windoze software decoder, works fine. There are patches for mplayer to use coreavc, and there is a wrapper for running coreavc on linux.

Yea, I know. I'm already running mplayer with the mt patches.
The thing is: I've got a hw-acceleration capable graphics card. I should be doing this in hardware, not software. With the HTML5 push, HD content will be even more widespread.

[droidhacker]

I'm not suggesting otherwise.
Just adding on a little to what was said by rohcQaH.

As far as hardware accelerated video decode, its coming one day to open source, just not today. It is also not yet clear what form this video decode acceleration will take... be it through the UVD stuff, or just straight on the shaders (i.e. generic decode acceleration using gallium3d).

There are a few key issues that need to be worked through before we can have the decode acceleration for Radeon parts;
1) For UVD, we would need some kind of usable specifications for the UVD components in order to actually make use of it.
2) For gallium3d, we would first obviously require a gallium3d driver applicable for the hardware we are using.

We don't have ANY of this yet, so decode accel is still a ways out. Until we actually have this, we really have no alternative but to make do with software decoding.

As for your other questions regarding state of legal review, sorry, but you will definitely need to get someone like bridgman to answer those. I definitely don't have that information, and honestly, I don't expect that even he will be able to give you any kind of concrete numbers.

[Kjella]

But UVD only decodes parts of the video, a lot is decoded using shaders.

From what I understood, decoding is all UVD. However, it's possible post-processing is done with shaders, not sure about that. What's been said is that shaders can do some parts of the decode well, others probably not so well. Nothing beats dedicated hardware though.

[DanL]

Nothing beats dedicated hardware though.

..except beating a dead horse.

[bridgman]

The first part of the playback stack is dedicated hardware, the rest is done on shaders. It's probably correct to say that all the *decode* acceleration is done on dedicated hardware and all of the *render* (aka presentation) acceleration is done on shaders.

IP review for UVD has not started yet. There are some licensing issues we need to figure out as well.

[kernelOfTruth]

IP review for UVD has not started yet. There are some licensing issues we need to figure out as well.

at least it's queued up so it'll appear somewhere in the future

that would be amazing ! opensource driver with decent functionality, speed including "native" UVD / video hardware acceleration

[popper]

"Quote:
Originally Posted by bridgman
IP review for UVD has not started yet. There are some licensing issues we need to figure out as well."

at least it's queued up so it'll appear somewhere in the future

that would be amazing ! opensource driver with decent functionality, speed including "native" UVD / video hardware acceleration

now kernelOfTruth, be fair it's ONLY BEEN 387 DAYS since the UVD IP review was mentioned Right here on the board, you cant expect a Generic Industry standard AMD/ATI UVD Hardware ASIC IP Review to be Authorised, signed off, and started, let alone done and dusted so quickly; Next you will be asking other unreasonable questions like were are the closed source linux beta UVD HW Decode drivers and/or were are the pass this to play/use with the supplyed beta UVD ffmpeg/x264 patchs comment or two on the dev blog URLs, dont be silly you know the ATI executive want you to want and perhaps even Spend yet More of your hard earned cash to get a Nvidia HW assisted HD video decoder asic with full AVC HD decoder capabilitys from their CHEAP boards, and full docs available for it TODAY anyway... and stop being so bothersome to the AMD Executives up there in their tower

http://www.phoronix.com/scan.php?pag...u_mobile&num=1
"....We have benchmarked VDPAU and found it to perform very well in that under Linux it's possible to play HD videos with a $20 CPU and $30 GPU thanks to this video acceleration method. VDPAU is the best video acceleration / decoding API on Linux and is widely adopted by various multimedia applications, which is all in contrast to AMD's XvBA and their troubled implementation....."