AMD Releases UVD Video Decode Support For R600 GPUs

[chrisr]

Let confusion reign!

I have compiled the very latest Mesa from git for my HD4890, and have copied the libvdpau_r600.so.1.0.0 object into my /usr/lib64/vdpau directory. When I repeat the "mpv" test now, I get successful playback with "--hwdec=vdpau --vo=vdpau", and a core dump with "--hwdec=vdpau --vo=opengl".

The core dump is possibly due to a mismatch between Mesa 10.4-devel's libvdpau_r600.so and Mesa 10.1.5's libGL.so.1.2, because "--hwdec=vdpau --vo=opengl" seems to behave itself with a suitable value for LD_LIBRARY_PATH.

So the bottom line is that I can no longer parse a shred of meaning from this original statement:

A small Mesa patch is needed as well, cause the older hardware doesn't support field based output of video frames. So unfortunately VDPAU/OpenGL interop won't work either.

Yes, a small Mesa patch is needed, but it seems that "--vo=opengl" (and hence VDPAU/OpenGL interop) can still work just fine without field-based output of video frames!? And hence Mesa can safely advertise the GL_NV_vdpau_interop extension for my RV790.

[profoundWHALE]

Thank you to the team at AMD for continuing to support my laptop.

I love how involved they are with the community as well!

[chrisr]

Could the Mesa patches be back-patched into 10.2 / 10.3 please?

The Mesa patches for UVD video are trivial, and look like they could easily be applied to the 10.2 and 10.3 branches too. I think that it would be "handy" if userspace were ready for this new UVD support before the 3.18 kernel is likely to start reaching users... .

And Fedora 21 looks like it will be using Mesa 10.3.

[Kamerat]

RV550

Just out of curiosity. Is there any support for the RV550 (Mobility Radeon HD 2300) and is it the same UVD version as the RV610/RV630?

[dungeon]

Just out of curiosity. Is there any support for the RV550 (Mobility Radeon HD 2300) and is it the same UVD version as the RV610/RV630?

It should be supported i think because devs says now all chips which has UVD unit are supported .

According to wikipedia there was two mobility RV515: X2300 does not have UVD unit, but HD2300 has:

http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units#Mobility_Radeon_HD_2xxx_Series

[dungeon]

It should be supported i think because devs says now all chips which has UVD unit are supported .

But OK it is good question, you seems to found one r300 which has UVD that is interesting .

[Deathsimple]

It should be supported i think because devs says now all chips which has UVD unit are supported .

Well that's the point where the only best effort starts

The first problem is that in theory the released code should work on the very few R5xx boards that have UVD as well, but nobody ever tried it. Because of this we haven't activated the UVD block on this hardware. If somebody got the hardware in question a simple kernel patch should be enough to activate it.

The second problem is that the userspace code currently doesn't work together with the R300 driver. Should be trivial as well to hack that together, but again nobody ever tried.

[Deathsimple]

I also notice that glxinfo is advertising the GL_NV_vdpau_interop extension:

Ah! Thanks for the notification, that's just a bug. Going to provide a mesa patch.

I can't claim to understand exactly what is supposed to be happening here, but isn't the current implementation of GL_NV_vdpau_interop dependent on field-based output? And therefore broken for <= RV770?

The field based output is needed to correctly display the picture after decoding. E.g. you will still see the image, but it would be stretched and every second line will come from the wrong offset.

[dungeon]

Well that's the point where the only best effort starts

As long as UVD is there hope never dies .

If someone has r300 laptop with rare UVD, just sent it to this guy

[pali]

As long as UVD is there hope never dies .

If someone has r300 laptop with rare UVD, just sent it to this guy

SSH root access will be not enough?