Google releases SwiftShader OpenGL ES software rendering library as open source


Would it possibly be able to extend the OpenGL ES so that most of it runs on the GPU but the shaders and other unsupported stuff runs on the CPU?
 
Would it possibly be able to extend the OpenGL ES so that most of it runs on the GPU but the shaders and other unsupported stuff runs on the CPU?
This is an idea that comes up pretty regularly, but nobody has ever quite made it work. It tends to lost it's efficiency advantages due to the synchronization and transfer of data between the cpu/gpu in tightly-coupled renders. It's nearly always better just sticking to either the GPU or CPU, and then the GPU tends to be so much better at 'graphics' related tasks, it's often better to stick with it even if you have to use a 'worse' algorithm due to it's limitations.

For some things it's possible, like doing a pass 'after' the main render (often used for stuff like post-processing/edge detection/other stuff like that), but tightly coupling the two to 'share' parts of the render pipeline seem to be pretty much impossible (at least with a 'positive' performance impact)

(Even more annoyingly, certainly the 544 on the pyra technically could support quite a few more 'useful' features than GLES2 exposes, though I suspect if they've never been tested on hardware they "don't work" :p

Still, a quick check seems to suggest SwiftShader doesn't support ARM at all, so it'll probably be quite a bit slower than a well-optimised neon-using rasteriser.
 
After a quick check, mesa's newest built-in software rasterizer, llvmpipe, seems to be pretty efficient. However, it looks like it doesn't support ARM assembly.
 
Back
Top