BrookGPU
As you can see, even with those analogies in mind, the task is no simple one, and that’s where Brook came in. Brook was a set of extensions to the C language – "C with streams," as its creators at Stanford presented it. Concretely, Brook proposed to encapsulate all the management part of the 3D API and expose the GPU as a coprocessor for parallel calculations. For this, Brook comprises a compiler, which takes a .br file containing C++ code and extensions and generates standard C++ code that will be linked to a run-time library that has various backends (DirectX, OpenGL ARB, OpenGL NV3x, x86).
Brook had several merits, the first of which was to bring GPGPU out of the shadows and make it known to the “general public.” Indeed, when the announcement of the project was made, several IT Websites reported on the arrival of Brook – sometimes oversimplifying to the point of caricature: “The CPU is dead! GPUs are much more powerful and may soon replace them.” Five years later, that still hasn’t happened. And let’s be clear about this: it never will. On the other hand, looking at the successive changes in CPUs, which are orienting more and more towards parallelism (more and more cores, simultaneous multi-threading technology and the widening of SIMD units), and GPUs, which – conversely – are being oriented toward greater and greater flexibility (support for single-precision floating-point calculation, integer calculation and soon double-precision calculation), it seems obvious that the two are bound to meet eventually. So what’ll happen then? Will GPUs be absorbed by CPUs, the way math coprocessors were? Possibly. Intel and AMD are both working on projects of this type. But in the meantime, a lot can still change.
But let’s get back to our topic. If Brook’s initial advantage was that of popularizing the concept of GPGPU, the API wasn’t limited to a PR role. It also greatly simplified access to the GPU’s resources, enabling a lot more people to start learning the new programming model. On the other hand, despite all Brook’s qualities, it still had a long way to go before it could make GPUs credible calculating units.
One of the problems encountered stemmed from the different layers of abstraction, and in particular the excess workload generated by the 3D API, which could be considerable. But the real problem, one over which Brook’s developers had no control, was compatibility. It’s not rare for GPU manufacturers to optimize their drivers regularly, especially given the heavy competition between them. While these optimizations are (most of the time) a good thing for gamers, they could break Brook’s compatibility overnight. That made it hard to imagine using the API in industrial-quality code intended for deployment. And so for a long time, Brook remained the province of curious researchers and programmers.
