darkblu said:
yet another approach to GPU-assisted theora decoding is passing individual 8bpp textures for the Y, Cb and Cr, respectively, and doing all the colorspace conversion onboard the GPU. A nice feature of that approach is that each of the chrominance textures is 1/4 the resolution of the luminance one, and the final, on-GPU stage gets 'free' scaling of the chrominance textures through the GPU's TUs.
The blog linked mentions this:
"Because there was already work underway to provide OpenGL accelerated compositing in Firefox with the newly conceived
Layers API, it seemed logical to try using a GLSL fragment shader to off-load colour-space conversion to the GPU. This turned out to be too slow to play back a full-screen video. Looking at the list of vendor-specific OpenGL extensions available on the N900, I discovered the
texture streaming API. This allows a program to directly map texture memory and copy Y'CbCr data into that memory without having to perform an expensive texture upload or colour-space conversion. The colour-space conversion is off-loaded to dedicated graphics hardware inaccessible via the standard OpenGL APIs. Using this and the modified bc-cat kernel module from the
gst-bc-cat project, it's possible to play back at 26 FPS with 81% CPU idle.
One drawback of the current bc-cat kernel driver is that there is a very limited set of texture formats supported (NV12, UYVY, RGB565, and YUYV), and none of them are the same as what Theora produces. To work around this, a format conversion is required to convert planar Y'CbCr to packed 4:2:2 UYVY. Fortunately, this conversion is much simpler than a full colour-space conversion. Timothy Terriberry sent me a
couple of patches to off-load this conversion work to the DSP. If it's possible to extend the bc-cat driver to support texture formats compatible with Theora's output, performance can be further improved."
IMO the CPU-utilization figures are misleading, because they suggest color space conversion takes 80% of the decode time, which would suggest a pretty lame compression. What you actually see from the FPS numbers (47->26) is that the SGX performing colorspace conversion is probably a pretty substantial bottleneck.
If you think about it it's not very surprising - let's say SGX was at 110MHz. It has only one TMU, so it takes at least 3 cycles to load the texture values, but I think it's actually worse than this because the textures are big (800x480x8bpp, 2x 400x240x8bpp) and unswizzled, and will probably cause many cache misses, especially if the L1 tex caches are only say, 2-way set-associative. Then you pay for cycles for the colorspace conversion that's probably performed in shaders.
The format limitation suggests to me that it was done was using OGL ES 1 instead of 2. So maybe the results can be optimized with better shaders.
I sent an e-mail to Matthew asking if he knew what the SGX was clocked at for this test.
Another thing is that the DSP port was probably not optimized for the DSP - I say this because it was mentioned that it was done quickly. So maybe much more performance can be squeezed out of it, so it's more competitive with the ARM optimized version.