Holy Crap! You Can Use XvMC With ATI Gallium3D!

[marek]

Latest git commit starts the iDCT implementation. It is nice to see this project progressing!

I wonder how much work is left until this can be merged to master?

Are you sure? That commit has nothing to do with video decoding. The commit message basically says "For hardware without vertex processing units, where vertex shaders are executed on the CPU using the auxiliary Draw module, return the shader capabilities of the Draw module to a state tracker, instead of returning the capabilities of unavailable vertex units." It makes the GLSL compiler generate, say, more CPU-friendly code.

I wonder what I stated wrong in that commit message that it caused such a confusion.

[HokTar]

Are you sure?

I wonder what I stated wrong in that commit message that it caused such a confusion.

Hehh, nice catch! I simply had two git tabs open in firefox and linked the wrong one.

My apologies, this is the real one, I believe.

If I'm already at it I would like to thank you for your work! It's always highly appreciated!

[HokTar]

If anybody is interested Christian just announced that iDCT is implemented and is working for him with r600g. He also noted that it still needs some work, but I hope that it will be merged to master soon.

After that hopefully h264 will come! That will be the real win.

As Alex noted in his reply:
Nice work!

[edgar_wibeau]

Hello HokTar,

yes I'm very interested and I've not heard anything about this topic since, well, last year. Do you/ does anybody know what's going on? I'm watching X.Org RadeonFeature for a long time now, but the only thing that's constant is the shader CoDecs being "WIP" for (feels like) two billion years now. Unfortunately my skills don't surpass shell coding (by a noticeable margin), otherwise I'd have done all the work myself

I know AMD has opened up their XvBA stuff, but that's hardly a solution for open saucers and UVD stays tightly locked up for us :-( Plus, it doesn't do any good when it comes to ENcoding, nor when CoDecs are to be used, which UVD/2/3 has no (or little) hardware for.

[HokTar]

FYI Corbin wants to merge pipe-video to master which seems promising.

Also, Christian refreshed his git repo recently so he is still hard at work.

[edgar_wibeau]

Sounds great, thanks for the info!

And please keep us up-to-date, at least if there's no new article on this topic at phoronix.

[89c51]

FYI Corbin wants to merge pipe-video to master which seems promising.

Also, Christian refreshed his git repo recently so he is still hard at work.

what video formats/codecs are supported by pipe-video ????

and it will have to be "presented" to the applications in order to use it right??

[HokTar]

what video formats/codecs are supported by pipe-video ????

As far as I know this branch contains the video layer for gallium (g3dvl) so it can accelerate xvmc.
There is also an initial commit for the vdpau state tracker.

Note that it has none of the work done by Christian Konig! Hopefully after this merge his commits will land soon.

and it will have to be "presented" to the applications in order to use it right??

I think the players simply need to support the decoder, i.e. xvmc or vdpau, so ideally it will work out-of-the-box with mplayer, etc.

[89c51]

ok thanks

it would be nice to have h.246 and VP8 acceleration at some point without having to rely on the GPU decoding hardware

[HokTar]

it would be nice to have h.246 and VP8 acceleration at some point without having to rely on the GPU decoding hardware

That is exactly Christians' goal. (h264)
Veerappan (Phoronix member - see this thread) is working on an opencl vp8 decoder so we would need clover to move along. Unfortunately, Zack Rusin is not working on it at the moment.