The UVD/UVD2 thread.

[Qaridarium]

The problem is that our requirement is not to "protect BluRay until someone cracks it", it's to "provide a ruobust environment where protected video content can be processed and displayed securely". Hacking BluRay encryption doesn't change anything, unfortunately.

Processed and Displayed securely LOL!

in the last way the human will cam the shit analog from the display...

yes very secure!

[MartjeB]

Don't blame ATi, blame Hollywood..

[deanjo]

Don't blame ATi, blame Hollywood..

Blame the voters who put the politicians in office that allow that crap to even be legal.

[xyzzy]

giving up

Oke, I waited long enough, I am going to buy another videocard.
I bought a 4350 and believed UVD2 would come, but now ATI is so much
behind xvdpau, they will never catch up anymore.

[Kano]

Well if you really need h264 accelleration then you lost, xv is working fine with oss driver.

[Qaridarium]

Well if you really need h264 accelleration then you lost, xv is working fine with oss driver.

you are an dark angel a real Opensource killer...

UVD was not the only way to accellerat h264.

the Opensource driver will do this over the shader units via OpenCL style!

so you kill Opensource! and he is a winner becourse he has a opensource cart!

[Kano]

Why do you think emulating this using shaders is efficient when there is already a dedicated part in the chip for that purpose? Then you can use raw cpu power too, because you only need about 3 ghz cpus and those will get cheaper over this year - when you oc a cpu it is already cheap.

[deanjo]

Why do you think emulating this using shaders is efficient when there is already a dedicated part in the chip for that purpose? Then you can use raw cpu power too, because you only need about 3 ghz cpus and those will get cheaper over this year - when you oc a cpu it is already cheap.

I doubt he will understand that. Try in his tongue.

openCL=GPU in highest power state

GPU in highest power state power consumption > CPU in highest power state power consumption

GPU in highest power state heat > CPU in highest power state heat.

openCL = more power consumption + more heat

vdpau netbook/notebook user = Lord of the Rings Extended Edition

openCL netbook/notebook user = an episode of MacGyver + roasted testicles + looking for power plug-in

[Vighy]

I doubt he will understand that. Try in his tongue.

openCL=GPU in highest power state

GPU in highest power state power consumption > CPU in highest power state power consumption

GPU in highest power state heat > CPU in highest power state heat.

openCL = more power consumption + more heat

vdpau netbook/notebook user = Lord of the Rings Extended Edition

openCL netbook/notebook user = an episode of MacGyver + roasted testicles + looking for power plug-in

funny, but most of all: true!

[deanjo]

funny, but most of all: true!

Thank you. Just wanted to make it as clear as possible as he seems to have some delusions that any tech that is not opensource is the death to it which is far from the truth. Ultimately a large part of that falls upon the opensource developers themselves and their willingness to work with their closed counterparts.

His "counter point" basically has little merit. Yes openCL could be made to handle x264 playback. No doubt about it. Can it do it efficiently? Not likely. GPGPU solutions only achieve their stellar efficiency when taxed enough to compensate for the additional draw on resources. A pickup truck (vdpau) will always be more efficient hauling around a refrigerator then a semi tractor (openCL at least pertaining to a usage on a GPU) hauling around the same fridge. Even a car towing a trailer (CPU decoding) will have better efficiency.

So where does openCL and kin all fit in to video? It's more suited for loads that can truly benefit the massive data parallelism that can offer. Such video applications that can benefit from that are jobs like encoding, transcoding, filtering and effects in real-time for example. It can even benefit audio. A real time complete FIR crossover could be done with GPGPU. Currently it cannot be done on a CPU without loosing time accuracy and experiencing some serious latency. Now couple that with multiple channels and the situation gets worse.

Applications such as this is where GPGPU fits into the grand scheme of things. It gets even better when coupled with solutions such as vdpau. Imagine being able to apply all your video effects on the fly in real-time and seeing the end results as well without frame drop, or being able to slam that 2 channel audio into a 7.1 stream with real time processing. Pure sweetness (not to mention diminishing dedicated hardware solutions like creative offers).

openCL is not a replacement for hardware playback of x264 and the likes. Encoding and processing is where it's strength lies.

( I do find Kano being accused of being the death to opensource quite funny though considering his background. He just calls it as he see's it, honest, truthful and usually with out blind fanaticism . Now his clubbing of baby seals on the other hand..... )

BTW Nvidia has openCL drivers to download if your part of their developer program.