3D Graphics Programming with Intel’s Larrabee

AnandTech has published a big article on Intel’s Larrabee architecture. Larrabee is not a GPU, it is a CPU with many cores (around 24 from this page)optimized for data-parallel processing. What’s the difference? There is very little fixed function hardware, and the hardware is targeted to run general purpose code as easily as possible. The bottom lines is that Intel can make this very wide many-core CPU look like a GPU by implementing software libraries to handle Direct3D and OpenGL.

In page 3, we learn that Larrabee’s default OpenGL / Direct3D renderer is tile based.

Programming for Larrabee
There are 2 options to program for Larrabee: writing standard Direct3D / OpenGL code, or writing directly to the hardware using Larrabee C/C++ (writing directly to Larrabee gives you some additional programming flexibility). Intel has written its own Larrabee native software renderer to interface between Direct3D/OpenGL and the Larrabee hardware. In AMD/NVIDIA GPUs, DirectX / OpenGL instructions map to an internal GPU instruction set at runtime. With Larrabee Intel does this mapping in software, taking DX/OGL instructions, mapping them to its software renderer, and then running its software renderer on the Larrabee hardware.

I can’t wait to test how Larrabee can run OpenGL code mostly the ones that have heavy pixel shaders that make a GTX 280 a level entry card…

Read this very interesting article here: Intel’s Larrabee Architecture Disclosure: A Calculated First Move.

Update (2008-08-07)
Related links:

One thought on “3D Graphics Programming with Intel’s Larrabee”

  1. MaxPan

    Adding even more multi-core compute is not what we need.

    Current trends in microprocessor evolution indicate that more and more applications will become memory-bound and be unable to benefit from the ample compute resources offered by the next generation of computers.

    This increasing disparity between a system’s compute capabilities and the available memory bandwidth needed to fully utilize that compute is the real problem.

    Until the memory bandwidth issues are solved, adding more compute won’t make a dent at speeding up performance for applications like ray tracing – that’s the real bottleneck that needs to be addressed.

Comments are closed.