081224 / Larrabee

previous | next

Merry Christmas All!

From SIGGRAPH Asia 2008: Parallel Computing for Graphics: Beyond Programmable Shading,

Larrabee

Intel, why have a CPU when you could have a Larrabee?

Larrabee is finally set to have many of the things I personally have wanted in a CPU (yes CPU) for some time. I'd rather have a Larrabee than a Core7 as my CPU. Unfortunately it seems as if Larrabee isn't going to be realized as a CPU? Kind of like Porsche never placing a good engine in the Boxster because it would upset the bread and butter 911, my wild guess is that possible low margins of Larrabee in competition with NVidia and AMD GPUs will insure Larrabee never sees a CPU role. Perhaps I'm 100% off on this assumption. Anyway it will be interesting to see what ends up as price/wattage/performance of Larrabee vs GPUs. Will Intel pull it off, and what is the response going to be from NVidia and AMD? Will programmers go Larrabee native and make use of the platform, or will a majority stick to DX11/OpenGL3/OpenCL? Non-native, will Larrabee have good small triangle performance? Will 4x4 fragment groupings be fixed, or will they software merge fragments to fill out SIMD vectors for small triangles? How will software binning do with upwards of 200-1000 bins and millions of triangles per frame? Will triangles even matter on Larrabee? Will I be tempted to do a Larrabee native app if market share is there (likely yes!)? Lots to see for 2009/2010...

General Info
- Coherent L1 and L2.
- 32KB L1 (not in SigAsia08 papers).
- 256KB L2 (not in SigAsia08 papers).
- In-order pipeline.
- No latency scalar ops.
- Low? latency on vector ops.
- Cheap? branch mispredict and cache miss.
- 4-way SMT designed to hide L1 miss.
- 16-wide float32|int32, 8-wide float64 (all math at 32|64-bit).
- SIMD one source from memory.
- SIMD fast predication on every instruction, 16-bit predicates.
- SIMD scatter/gather!
- Almost free? conversion to float16, int|norm-8|16.
- Cheap? conversion to other formats, sRGB, float11:11:10, norm10:10:10:2.
- Long-latency texture fetch.
- Support OpenGL and OpenCL!!!!
- Support Larrabee Native C/C++ applications!!!!!!!!!!!!!!!!!

Parallel Programming with Larrabee
- Work Item = One SIMD lane.
- Fiber = Software managed context, runs 16-64 work items.
- Fiber = logically assigned a part of L1.
- Thread = Hardware managed context!????
- Thread = Switches between 2-10 fibers to cover latencies.
- Switch = Start asynchronous texture fetch, then user-space context switch.
- Core = Independent processor that runs 1-4 threads.
- SIMD divergent branch = execute both paths with masks regs to predicate.

L1 As Extended Register File
- 32KB / 4 threads x 02 fibers x 16 work items = 64 32-bit "L1 regs" per work item.
- 32KB / 4 threads x 02 fibers x 64 work items = 16 32-bit "L1 regs" per work item.
- 32KB / 4 threads x 10 fibers x 16 work items = 12 32-bit "L1 regs" per work item.
- 32KB / 4 threads x 10 fibers x 64 work items = 03 32-bit "L1 regs" per work item.
- Requires range of 8 to 40 asynchronous texture fetches per core.
- Rough calculations ignoring other usage of L1...

Larrabee vs OpenCL
- Larrabee can submit work to itself!
- OpenCL cannot.

Larrabee on Graphics
- Color/depth/stencil buffers stay in L2.
- Binning, run in submit order, each pix does shading+OM.
- 64x64 or 128x128 tiles, tile = bin.
- Tile per core.
- Add triangles to overlapping bins.
- JIT for shaders and pipeline stages done on Larrabee itself.
- In bin, dice triangle to leaf 4x4 blocks.
- At leaf test sample locations?
- Texture soft fault on page miss (easy mega-texturing, easy procedural texturing)!

L2 As Framebuffer Tile
- 256KB / 64x64 = 64 bytes = (32bit depth_stencil x 4 MSAA + 6 64bit MRTs).
- 256KB / 128x128 = 16 bytes = (32bit depth_stencil + 3 32bit MRTs).
- Rough calculations ignoring other usage of L2...

GPU Binning

AMD's binning paper shows results for HD 4870 at only 1M bins in 0.02 seconds (50Mbin/sec) on 64^3 grid. Uses the multipass DrawAuto trick with StreamOut recirculation of non-binned points. Humm, the method seems a little too slow for me regardless of AMD or NVidia GPU. Too much overhead for the result. Say this was a GT280, at 141.7 GBs bandwidth, 50M/s points averages to over 2KB available peek bandwidth per point. Larrabee or OpenCL or CUDA should be able to mop the field with this sort of computation. Basically a vector gather queue position for 16 points, increment queue position + vector scatter result, and vector scatter point output based on queue position. So 3 memory ops per point, assuming a measly 128 GB/s bandwidth (for highend GPU) and full cache misses for all memory transactions (ie 64 bytes/transaction per SIMD lane) should be able to support upwards of 500M points/sec for binning. Assuming cache hits with Larrabee, then the numbers drastically change towards even better performance.