There May Still Be Hope For R600g Supporting XvMC, VDPAU

[Kano]

Every Evergreen or newer has OpenGL 4.x in the opengl version string and olders show 3.x. Why don't you use that?

[gbeauche]

Every Evergreen or newer has OpenGL 4.x in the opengl version string and olders show 3.x. Why don't you use that?

This is not sure, and you don't know if the same workarounds are necessary. Someone will have to check with the relevant XVBA_VIDEO_EVERGREEN_WORKAROUND variables. Checking for the OpenGL version string is silly.

[Kano]

That's maybe 99.9% sure...

[V!NCENT]

Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

Is it just me or is the world nuts? Okay...

[HokTar]

Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

Is it just me or is the world nuts? Okay...

Well, CPUs can play videos up to a certain level. My Turion X2 ultra (2.2GHz) can play 1080p with mplayer-mt, but with high bitrate scenes it struggles and drops frames, sometimes stops drawing new ones for ~5 seconds. I have a fairly good GPU, a HD4650 (rv730).

So here is the deal: if my GPU could do a little more work in the decoding process I might as well be able to enjoy all my videos.

Am I nuts?

[bridgman]

Bingo.

Many systems don't have *quite* enough CPU power to play the videos that users want to watch, so offloading even part of the decode work to the GPU can make a big difference in user experience. There are also formats which hardware acceleration won't handle today (VP8 is an obvious example but I'm sure there will be more in the future) so a general purpose, easily extensible solution will be useful in other ways as well.

You might still be nuts but not in this specific case

[bridgman]

There is also the obvious point that if we are not able to open up UVD programming information then shader-assisted decode is going to be a nice thing to have even if it only implements prediction/MC and filtering.

[HokTar]

...if we are not able to open up UVD programming information...

Yes, I wanted to mention that you never said that you won't as Michael wrote in the article. You wrote in the other forum that you will look at it and in 6 months you will be able to tell if it will ever happen or not.

So, for example the vdpau state tracker would eat the vdpau calls from mplayer and turn them into tgsi intsructions* then the r600g driver would eventually display it.

*: Well, I think tgsi will be turned back to glsl ir by the driver first, then it would get optimised and fed back to the driver to actually display something. Right?

You might still be nuts but not in this specific case

Thanks. :P

[HokTar]

Let's assume we have a working vdpau state tracker with r600g.
Now how could we add vp8 decoding possibility to this?


1) The shader based version which was started eons ago needs to be done for all formats, right?
2) An opencl based solution would require a working opencl state tracker and the ffmpeg guys to write decoders for each codec.
3) The vdpau state tracker needs to be written only once and then we've got to wait for nvidia devs to implement support new formats. Maybe some modifications are needed afterwards.

Assuming the above points are correct the 3rd option requires the least amount of xorg work I think. Plus it would work immediately.
The 1st option seems pointless.
The 2nd option is interesting, because ffmpeg devs are interested in that and that state tracker could be used for several other projects, too.

So I am actually confused; why haven't the xorg devs written a proper opencl state tracker with good driver support and said that:
"Write opencl code and don't ever mention again uvd/xvba/vdpau/vaapi!"?
It seems much easier to me and the end result might as well be better than with any other option.

Conclusion:
The fastest solution is what is in the article, the "vdpau state tracker for r600g".
The best would be possibly the opencl one but there is no such decoder at the moment so it wouldn't solve the situation right now.


One more thing:
So the decoder is now written in c/assembly which runs on the cpu or gpu (through vdpau/xvba/vaapi).
If it was written in opencl then it could run on the cpu, the gpu or both. In this case vdpau/xvba/vaapi won't get touched but the drivers' opencl capabilities will be used.

Please correct me if I am wrong somewhere!

[W3ird_N3rd]

Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

Is it just me or is the world nuts? Okay...

CPU's actually can do 3D graphics, but they suck at it. We already had 3D games before the everybody started installing Voodoo cards.

As said, videos with a high bitrate are hard to decode using just the CPU. Also, the GPU can often do it using far less power. Don't be surprised if GPU decoding uses 30 watts less compared to having the CPU do the same thing. Apart from the slightly lower electricity bill this mostly reduces fan noise and, in case of laptops, improves battery time.

So yeah, call me nuts..