I only briefly looked at the source code, but I can confirm that the shader compiler, like almost anything else, is indeed just called via RPC into the VideoCore.
Describing this as a fully open source graphics stack is of course a gigantic marketing stunt, but I also agree that it is a major step forward. Not so much because of the technical merits of that code but because it shows how even a company that is as closed as Broadcom can move towards an open ecosystem, and because it provides a good argument to counter all the SoC and GPU companies that require proprietary blobs running in user space or even in the kernel.
It's worth mentioning that the same GPU is used in the BCM28145/55 smartphone SoCs, and I really hope that having a completely open user space implementation gives Broadcom an advantage in Android products that leads to other companies moving to even more open graphics stacks.
Since you mentioned other implementations: are you aware of any GPU besides this one that has everything including the shader compiler in the GPU itself and can do the same trick?
Posted Oct 24, 2012 21:15 UTC (Wed) by swetland (subscriber, #63414)
[Link]
Nope -- every other GPU implementation I've seen thus far requires the shader compiler and even the general translation from OpenGLES API to native formats and command queues to happen on the host side. Including a full general purpose processor in the GPU block is unique to Broadcom to the best of my knowledge (though it is similar to how a lot of codec blocks work -- a pretty powerful, relatively general purpose cpu or dsp combined with dedicated hw accel units for heavy lifting).
Raspberry Pi VideoCore driver code released
Posted Oct 24, 2012 23:30 UTC (Wed) by pabs (subscriber, #43278)
[Link]
The best thing about giant marketing stunts is that they can be used as blunt objects to beat other vendors with :D