Eben Upton stated quite clearly that this was the case in one of his comments on theraspberrypi.org where he said:
I'd really like some of the critics to engage with Eben's point, ideally without name calling. In this situation, it's clearly easier to release the ARM-side GPU driver, fewer IP issues for a start. This may explain why Broadcom were able to release this code at all, but that doesn't make it misleading to say that they've released the complete device driver!We happen to have a GPU which exposes a comparatively high level (GL-like) interface, such that many of our userland functions are message passing shims... These are design decisions on the part of the respective GPU teams, which have wide-ranging implications for the software and hardware structure of the devices which use the resulting cores. The VideoCore driver isnít structured this way to pull the wool over your eyes, itís structured this way because of a genuine judgment that this is the best structure given the resources we have on the chip, which includes a vector DSP to which we can offload much of the low-level register access.
If you think it'll help, you can define the Broadcom GPU as a). a bizarre design or b). not a GPU at all, as some commenters seem to imply. I'm not sure how that helps the discussion?
The GPU exists, the Raspberry Pi team choose to use it, now they've persuaded Broadcom to open up the admittedly thinner-than-you-might-expect GPU driver. Useful? yes! Perfect? no. Misleading? no!
- Just my opinion; your mileage may vary.