OpenCL 1.1 Specification Released

[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]

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.

[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]

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!

[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

[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?

[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.

[Qaridarium]

Agreed, but (a) I wasn't aware of any open source OpenCL-on-CPU implementations, and (b) at least this would allow chaos386 to stay with the open source graphics drivers (probably).

in my knowledge the steam sdk for openCL only supports SSE3 cpu's...

if you have an old opteron you only have SSE2

this is what you so called "chaos386"

in my point of view the linux-amd64 standard is SSE2! thats because the first 64bit cpus are SSE2!

but ok amd wana have the speed of sse3... means 'chaos386'

[Qaridarium]

LOL chaos386 is a member name in this forum... sorry ...

[Qaridarium]

They had no reason to build one. If you want to use GLSL acceleration that still can be done on a 8800 GTS. XBMC has had this option available for quite some time now.

"They had no reason to build one"

why not? just nvidia sucks?

"If you want to use GLSL acceleration that still can be done on a 8800 GTS."

if i? sure not the only solution for an geforce8800 customer is to sell this card on ebay and get real amd hardware ;-)

why is nvidia not progamming a GLSL solution for 8800 customers ?

i know why... because GLSL isn't working well for that.