3 ms·
Quote from x264's assembly guru: <holger_> whatever this guy did, 600x faster suggests a suboptimal cpu implementation and/or a very memory intensive workload.
by Kovensky 16y ago
Quote from x264's assembly guru: <holger_> whatever this guy did, 600x faster suggests a suboptimal cpu implementation and/or a very memory intensive workload.
The GPU, looking at each individual core, is actually a very weak general purpose processor. GPGPU is good for because there are a lot of cores, so you can run highly parallelizable tasks easily in it.
Video encoding is not one of these tasks since each block depends on the previous block, each frame depends on the previous, and even on the next frame.
There have been uncountable proposals to port or accelerate a part of x264 on GPGPU. Nobody has succeeded in two years, not even for the motion search, which is supposedly the component that would be the easiest to port and benefit the most from GPGPU.
- chmike 16y agoYou point it. The algorithm I implemented is memory intensive and I used the texture map storage. It is the backprojection of tomographic reconstruction. Computation is very light. I expect that video encoding has the same pattern. One of the critical aspect to benefit from GPU parallelism is the amount of state information each thread has to maintain. It has to be kept to a minimum because this space is limited. If they need more space the number of active threads is reduced to match the requirement.