OpenCL 1.1 Specification Released

[bridgman]

D'oh !!

Good point, I'll check into that. Thanks !

[bridgman]

Yep, that looks like the kind of thing I'm talking about. The problem seems to be that most of these decoders are implemented as summer projects and the work takes longer than a summer

The basic ideas seem pretty straightforward :

- bitstream decode, entropy decode and modified IDCT on CPU (the H.264 version of IDCT is cheap to execute)
- intra-prediction on CPU, at least for I-frames

** move data to video memory on GPU ***

- motion comp (aka inter-frame prediction) on GPU
- blend with residuals on GPU
- deblock filter on GPU
- all decoded frames stored on GPU

I don't remember if B and P frames also use intra prediction or just inter prediction (mo comp) - if they do then that's probably going to be the nastiest part of the implementation.

[Veerappan]

I haven't actually seen any shader-assisted H.264 decode implementations in public yet, have you ?

It's very common to use shaders for render aka presentation (scaling, colour space conversion, post processing etc...) but I haven't seen anything that does MC, deblock and loop filtering on shaders and everything further upstream on CPU.

I was looking around yesterday afternoon for stuff like this, and found this thread on the XBMC forums about a GSoC project which a few other guys are picking up:

http://forum.xbmc.org/showthread.php?t=33802

It's not done yet, and it's using an older version of the ffmpeg source, but they do have the beginnings of a OpenGL+GLSL H.264 implementation. I haven't read the whole thing yet, but on the last page (10 as of yesterday, I think), there's a link to a github.com repository which has compiling code, although I think it currently freezes when playing videos.

Would this be something like what you were describing?

[V!NCENT]

think that is only partly true... since if for instance openCL requires features in the hardware driver that no other state tracker has needed yet that would still have to be implemented in the driver so drivers still have to be worked on independantly to some degree though probably not nearly as much as before.... thats just how it seems to me.

Yeah OK, but that wasn't my point. My point was that once all the work on the functionality of (the) OpenCL (state tracker) is done, that work doesn't have to be done all over again for each and every driver.

I read about it before on the Phoronix forums. For example; nasty race conditions =x

[BigFatGangsta]

The architecture of GPUs often lend themselves to various tasks (such as video decoding) with far less power than a CPU. This is quite important in laptops, HTPCs (less fan noise), mobile devices, etc.

Ok, so it does consume less power when doing video decoding on GPU. Now Im happy and see why its worth the trouble. Thanks!

[mirv]

I agree the CPU is relieved of the load if the GPU is doing the decoding. But that is not the point. The GPU is just another processor. And if nearly all CPU:s are strong enough to decode video and still have a lot of horsepower left for other tasks. Why put a lot of effort in moving the decoding into the GPU? I could see the gain if it was a trivial effort and for small devices. But not for modern desktops and laptops..

May be its just cool to do stuff on the GPU.

The architecture of GPUs often lend themselves to various tasks (such as video decoding) with far less power than a CPU. This is quite important in laptops, HTPCs (less fan noise), mobile devices, etc.

[BigFatGangsta]

Yes, there is. CPU could be relieved by the GPU and in the time when most people do multitasking on their PCs the video decoding is not the only task to do for CPU and multiple CPU cores does not help in any case.

I agree the CPU is relieved of the load if the GPU is doing the decoding. But that is not the point. The GPU is just another processor. And if nearly all CPU:s are strong enough to decode video and still have a lot of horsepower left for other tasks. Why put a lot of effort in moving the decoding into the GPU? I could see the gain if it was a trivial effort and for small devices. But not for modern desktops and laptops..

May be its just cool to do stuff on the GPU.

[xeros]

I was thinking about what is the big gain by doing video decoding on the GPU?

Yes, there is. CPU could be relieved by the GPU and in the time when most people do multitasking on their PCs the video decoding is not the only task to do for CPU and multiple CPU cores does not help in any case.

[BigFatGangsta]

Is there really so much advantage doing decoding on GPU?

I was thinking about what is the big gain by doing video decoding on the GPU?

It will let people with weak cpu:s watch hd video, thats true. But less and less people have cpu:s that cannot handle hd video. So that reason for doing video decode on gpu is decreasing as time passes.

So by the time all this is implemented properly in OSS drivers. Maybe it is not all that useful for the big majority?

Is it consuming less power when doing video decode on GPU versus CPU? Its still the same amount of decoding that has to be done. So which processor that does it shouldn't matter? Right?

A lot of questions and maybe Im way out of line in my thinking...

[bridgman]

I haven't actually seen any shader-assisted H.264 decode implementations in public yet, have you ?

It's very common to use shaders for render aka presentation (scaling, colour space conversion, post processing etc...) but I haven't seen anything that does MC, deblock and loop filtering on shaders and everything further upstream on CPU.