If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Combined with accelerated video decoding, it makes sense to offload more stuff to the GPU. This way all CPU cycles can be devoted to encoding, and the bus traffic is minimal. Handbrake would only need to push the compressed source video data to the GPU and would read back cropped and scaled frames, and encode these. I'm sure that is what it is doing...? The release notes aren't very clear about it.
People are not reading the announcement very carefully.
1. HandBrake OpenCL is Beta
2. It's not in the 0.9.9 release
As a rule, HandBrake doesn't release major features till they work on *all* platforms we claim to support (windows, osx, linux). So when it's ready, it should be working on all. Intel QuickSync is also in the pipeline.
It would be nice to see some benchmarks. It seems that the supported operations are cropping and scaling.
Given that the PCI transfer is extremely expensive, and scaling and cropping rather cheap operations, I'm surprised that this is worthwhile.
On the other hand, it's probably just a first step, with more complex operations planned in the future.
Well, just tried a couple of encodes on my 8350/titan system. Didn't make a whole lot of difference on a quality based encode, resized from 1080 to 720 with cropping. With openCL 20m32s, without openCL 20m3 seconds. It was using the Titan but barely, gpu load never exceeded 9%. Now QuickSync accelerated on the other hand......6m5s
You have to transfer the video to the graphics card anyway because of the connection to the display.
The most optimal way would be to load the video into the graphics card memory and decode, composite and post-process on the graphics card. The graphics card is much better suited for graphics calculations and it frees the CPU for other tasks.