AMD's UVD2-based XvBA Finally Does Something On Linux

[droidhacker]

Originally Posted by bridgman

I don't understand your question. I'm talking about the R600 (aka HD2900) but you linked to the HD3000 Series page (ie different chips).

The R600 did not have UVD. The RV610/HD2400, RV630/HD2600, RV620/HD34xx, RV635/HD36xx and RV670/HD38xx all had the UVD1 block. 780G and RV7xx parts have UVD2-family decoder blocks.

The primary difference between 780G and 780V is that the 780G has UVD while the 780V does not -- the 780V is aimed at business systems where efficient video playback is a drawback, not a benefit

NM, I think I'm understanding now... there is a distinction between R600 *family* vs R600 *specifically* (i.e. RHD2900).

Also, I found this document here:
http://en.wikipedia.org/wiki/Compari....2C_HD_4xxx.29
*** shows that RHD3200/780G is an RV610 (UVD1), not a UVD2. Or is that a "special" RV610 with UVD2? Because this document: http://en.wikipedia.org/wiki/UVD#UVD_enabled_GPUs claims that 780G is a UVD1 also...

not that wikipedia is infallible though....

[bridgman]

Yeah, we normally refer to 6xx for the family (HD2xxx, HD3xxx) and 600 for the chip. The potentially confusing part is Mesa HW drivers, where "r300" handles the 3xx-5xx plus rs6xx and "r600" handles 6xx-7xx and probably Evergreen.

The 3D core of 780 comes from rv610, but the UVD is different - closer to the UVD2 in the other 7xx parts than the UVD1 in 6xx parts. In general the IGP parts have the newest display controller and UVD hardware available at the time, plus a 3D engine from an earlier generation and a totally different memory subsystem.

[SP8472]

I've got it to work (sort of) on a Debian amd64 box with a Radeon HD 4350 card. Video plays, and looking at CPU usage in htop makes it very clear that there is in fact hardware acceleration in use.

However, there are color issues with the video. The colors aren't completely wrong, but there are green and red blotches moving over the image, most noticeable on people's faces. The video looks fine with software decoding, and this happens with different video files (all files I've tested were H.264, though).

Is this a known issue? With a known workaround, maybe?

[chrno]

Originally Posted by bridgman

R600 doesn't have UVD. It was a pretty big chip already and it had enough shader power and bandwidth to do a fair amount of decode acceleration on the shaders.

I'm eyeing a PCI-based graphics card with a "Radeon HD 2400 Pro" (RV610) GPU on it for a completely F/OSS-compatible HTPC. Any guesstimate as to whether or not it too will have "enough shader power and bandwidth to do a fair amount of decode acceleration on the shaders"? In particular, do you think it will allow (eventually!) playback of 1080p material?

If anyone knows of a PCI-based graphics card with a faster GPU and a decent shot at F/OSS drivers with decode acceleration I'd like to hear about that too.

[Chad Page]

Originally Posted by chrno

I'm eyeing a PCI-based graphics card with a "Radeon HD 2400 Pro" (RV610) GPU on it for a completely F/OSS-compatible HTPC...
If anyone knows of a PCI-based graphics card with a faster GPU and a decent shot at F/OSS drivers with decode acceleration I'd like to hear about that too.

There are 4350 PCI cards out there too, which have more shader power and might get working UVD2 someday.

I don't know how Noueavu's doing with the video decoders on GeForce cards.

[murphy]

Hi,

does anyone know, how to deal with this message?

$ vainfo
libva: libva version 0.31.0-sds3
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA API - 0.5.1
vainfo: Supported profile and entrypoints
xvba_video: XVBA_CreateContext(): status 11
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 0 ()
Serial number of failed request: 12
Current serial number in output stream: 12

[bridgman]

Originally Posted by chrno

I'm eyeing a PCI-based graphics card with a "Radeon HD 2400 Pro" (RV610) GPU on it for a completely F/OSS-compatible HTPC. Any guesstimate as to whether or not it too will have "enough shader power and bandwidth to do a fair amount of decode acceleration on the shaders"? In particular, do you think it will allow (eventually!) playback of 1080p material?

If anyone knows of a PCI-based graphics card with a faster GPU and a decent shot at F/OSS drivers with decode acceleration I'd like to hear about that too.

Another vote for either HD4350 or 4550 (same GPU core, different RAM and clocks). If you want to pick up something from an earler generation I would go with at least HD2600/HD3650.

[makomk]

Originally Posted by johoja

Actually.....the 7xx was very very different compared to the 6xx asics.

The major difference between uvd, and uvd2 is the mpeg decode part.

Yeah, that makes sense. Just tried this on my Radeon 2600 HD, and h264 decoding seems to work fine. MPEG2 and MPEG4, on the other hand, don't. (OSD/subtitles don't work, but that's going to be a bug in the mplayer patch.)

Originally Posted by blindfrog

It's just good that it supports freedesktop.org's "standard" api for video accel VA-API will be highly likely get implemented more since more or less both amd and intel are supporting it.

Not really. This requires an unofficial modified branch of VA-API that's not been accepted upstream yet.

[energyman]

Originally Posted by dosenpfand

The Hd Vid decoding support on GF7xxx Cards under Win is kinda limited, but annyway Nvidia supports more Generations of Cards with VDPAU

not really. 8XXX, 9XXX and 250 are basically the same generation. No, not basically. They are.

[gbeauche]

Originally Posted by makomk

Not really. This requires an unofficial modified branch of VA-API that's not been accepted upstream yet.

All core libVA changes are integrated upstream, but not released yet (version 0.31). You can check the GIT tree. The VA/GLX extensions are still work-in-progress but the API stabilised. There will be another change to support MPEG-4 ASP needs of VDPAU.