So, I'm glad that OpenCL-based video convertors are starting to come.
Open-source OpenCL is much better than proprietary NVIDIA-only CUDA.
Open-source OpenCL is much better than proprietary NVIDIA-only CUDA.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Does Intel M3000 support hardware accelartion of Flash Video?
- Thread starter kristoffer4
- Start date
- Sort by reaction score
OK. Generally, decoder is a device which does the reverse of an encoder.
Only in case of transcoding they are doing the same.
When you're looking at little boxes connected through lines on a whiteboard: yes.
But that I meant was that you have other demands when you actually decode a video for viewing it in opposite to just crunching through the data.
But let's end here, we're going offtopic.
This is from an earlier article from cnet:
Source: http://news.cnet.com/8301-13924_3-20024079-64.html
There's also some related discussion over at anandtech: http://www.anandtech.com/show/4084/intels-sandy-bridge-upheaval-in-the-mobile-landscape/5 (see comments).
And the story gets a lot more interesting if we take a look at Intel's own forum: http://software.intel.com/en-us/forums/showthread.php?t=79766
So Intel does support OpenCL only it doesn't seem to have any products that is using it. Whether this is a matter of updating drivers to support OpenCL or they have to rebuild the hardware is unknown.
Yes, very true.
Apparently, the problem with GPU-accelerated video is that it doesn't produce the same level of quality as you can get with CPU-based codecs. I didn't know that until I started reading reports about Intel's Quick Sync technology where they did comparisons between GPU-assisted video transcoding and that done by the CPU and Quick Sync. Quick Sync was apparently designed so that it was a close match in quality to what you can get with pure CPU-encoded material.
Of course, very few probably care much about what Flash video looks like so this point may be a non-issue considering the original topic to this thread. Furthermore, I'm not certain whether this quality "problem" equally affects both the decode and encode. The reports I read compared the transcoding of high-quality original content into smaller, lower-resolution copies (just as might be done for YouTube or your iPhone/iPad).
If you want to check the OpenCL support and find out the truth,
here is a tip: you need to compile (using OpenCL compiler) a small program
that uses the following function:
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceIDs.html
The main problem is that you must have a notebook with Sandy Bridge,
I don't have a one yet, otherwise I would have checked it by myself!
That's a pretty super wild ass simplification and missing the point.
H.264 as a example was designed to be "quick" on decoding and "slow" for encoding. All so the decoding aspect can be implemented cheaply in silicon or software.
So no the encoder and decoders are not the same thing. They do quite different things. And the decoder blocks in all GPUs are a lot smaller than the multiple SIMD engines used for the rest of the GPU related functions. If you were to use the full GPU just for decoding you are going to be burning up batteries quite quickly. Not a good situation and one of the reasons why decoding is designed to be relatively light and quick for codecs like H.264.
This would be up to Apple to implement. They do not have VDAPU to stand on for this.
OpenCL is overkill for this comapred to using the dedicated decoding hardware on a GPU. It still makes me word why OpenCL is constantly brought up as a decoding solution among other panacea.
OpenCL is overkill for this comapred to using the dedicated decoding hardware on a GPU. It still makes me word why OpenCL is constantly brought up as a decoding solution among other panacea.