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

[bridgman]

I believe the current plan is to add video decode calls to Gallium3D itself, allowing the driver to either use dedicated decode hardware or shaders as appropriate.

Not sure, but I *think* this work has already started.

[tmpdir]

Yes, I actually updated the technical details on that page a couple of times, although my updates were reverted because they didn't match gossip on other forums. Yay.

As always, can't comment on unreleased features.

-Laugh-

[tmpdir]

VAAPI isn't necessarily a bad choice here - in fact it means we now have 1 api that covers all major hardware since there is also a VDPAU backend for it.

Last thing I've read, va api only support vdpau partly.

[gbeauche]

So how well does this work together with compiz/kwin desktop-effects?
And what about tearing, with and without compositing?

It does, though only tested in Ubuntu. Concerning the tearing, since that version only has OpenGL, you have to enable always vsync in e.g. amdcccle. There is another means to get tear-free rendering without OpenGL but this is not available in public builds.

[gbeauche]

Last thing I've read, va api only support vdpau partly.

You will have to be more specific than that. You don't provide any information here...

[Kano]

@tmpdir

That's correct. Lets say that vdpau-video is the best backend for vaapi but there are still some drawbacks:

a) you can press D to deinterlace with -vo vdpau but not with -vo vaapi
b) h264 l5.1 usually fails

xvba-video has got some extra drawbacks:

a) No OSD/subtitle support at all.
b) mpeg2 is not fully supported, which is really bad as you still have to use only for that content type direct gl outout - on nvidia you can use vaapi for at least 3 content types, in theory with the dx10.1 cards even 4.

$ 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
      VAProfileMPEG2Simple            : VAEntrypointIDCT
      VAProfileMPEG2Main              : VAEntrypointIDCT
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

I would suggest to implement VLD for MPEG2 in software and use whatever ATI provides as hw part. A similar thing NV did for VC1 and older chips.

c) Bad clips can even crash the system - something i absolutely like
d) Some h264 content has got the wrong colors.

[gbeauche]

b) h264 l5.1 usually fails

Try to play with the extra "dm" option. e.g. -vo vaapi:dm=0 or 1 (whatever works) as a workaround. Something probably regressed.

xvba-video has got some extra drawbacks:

a) No OSD/subtitle support at all.

Well, not in a version you can use yet. ;-)

b) mpeg2 is not fully supported, which is really bad as you still have to use only for that content type direct gl outout - on nvidia you can use vaapi for at least 3 content types, in theory with the dx10.1 cards even 4.

It's not an XvBA limitation but a limitation of the underlying HW. The API won't magically implement something if the underlying HW doesn't support it.

[Kano]

As xvba-video is a wrapper it could contain software to implement missing parts.

[droidhacker]

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.

Then I'm confused... according to this: http://www.amd.com/us/products/deskt...00-series.aspx
HD3xxx series *does* have UVD. RHD-2xxx even.

Or is it just fake-UVD ala shaders (aka the gallium3d plan)?
If it is just fake-UVD, then why the distinction between R3100 (780V chipset) and RHD3200 (780G chipset)? 3100 just not strong enough? Or is it a question of being disabled in the drivers?

[gbeauche]

As xvba-video is a wrapper it could contain software to implement missing parts.

You will be duplicating code or producing inefficient code. The better thing is to support IDCT level acceleration. That's all, but not something I want to do now. That would be fine if you only had to maintain a single driver, not if you had several drivers that would need the same treatment.