Tweet
Originally posted by MartjeB
View Post
-
Blame the voters who put the politicians in office that allow that crap to even be legal. -
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.Comment
-
Well if you really need h264 accelleration then you lost, xv is working fine with oss driver.Comment
-
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.Comment
-
Originally posted by Kano View Post
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-inComment
-
-
Originally posted by Vighy View Post
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.Last edited by deanjo; 20 April 2009, 10:37 PM. Reason: No matter how hard I tried, I had to go back and correct the typo's and spelling. Qaridarium, it is a video CARD not a CART.Comment
-
Originally posted by Qaridarium
Wrong wrong wrong. You are confusing decryption with decoding.Comment
-
I knew it the other way around, too.Originally posted by deanjo View Post
Even Wikipedia thinks it that way.
That's a Unified Video Decoder we're talking about, and it (UVD2) aims at "full bitstream decoding of MPEG4-class video streams".
If using the UVD block, I assume that no shaders are involved in the video stream decoding. It would be... counterproductive, at least. Remember that the different iterations of UVD, are heavily based on the Xilleon decoder unit used in systems like TVs, where there aren't other "things" that could work as video stream decoders. And, yeah, a Xilleon is a complete MIPS SoC (probably a similar technology used by AMD while developing the Wii's northbridge/video chip/embedded MIPS).
OT: Qaridarium, you're making me crazy with that language of yours. Where did you pick it up? (joking)
Last edited by Loris; 21 April 2009, 05:56 PM.Comment
-
No UVD is the "Universal Video Decoder". Decoding and decrypting are 2 very different items. While UVD may contain a aes engine for decrytion as well that has NOTHING to do with rendering the stream. Decryption uses next to nothing for resources (anydvd does it quite fine in windows without any gpu usage). Your power hungry process is the decoding and rendering of the stream.Originally posted by Qaridarium
As far as power consumption goes, run ANY gpgpu solution and you will see for yourself what the power consumption is like.
and if your thinking of brute force decrypting a BluRay with openCL, lol, well, good luck with that 256 AES encryption with a room full of GPU'sLast edited by deanjo; 21 April 2009, 05:59 PM.Comment
Comment