Ah thanks, guess I should've run the math to see that you can actually do a lot with 256KB of L2. Are you sure that 4 MRTs are only 20KB though? I get 80KB even without MSAA (20 KB for each).
A colour pixel in a normal render target is 4 bytes + z/stencil is 4 bytes. 4x MRTs share z/stencil, so 4*4+4=20 bytes per pixel for 32*32=1024 pixels = 20KB.
Is the Larrabee model strictly one strand per pixel or is it possible to have relatively fewer persistent qquads iterate over sub-tiles within the tile? I guess nothing is strict when it comes to LRB....
There's four (hardware) threads per core, so each thread can support multiple qquads (fibres in the general sense, i.e. could be sets of vertices, etc.). So a strand is supporting a pixel from each of numerous qquads. Each qquad is, effectively, a different region of 16 pixels in the tile. So a thread with 8 qquads in flight, say, has 8 different pixels spread across the tile being processed by a single strand.
qquads could easily iterate over the tile as you say, but each thread would normally have multiple qquads in flight at a given time, as four hardware threads, in their own right, aren't enough to hide most memory/texture latencies.
Good point. I still wonder whether it would make sense for shared memory to double as a tile buffer. State storage won't be a problem as the register file will presumably continue to exist. But I guess for that to work you'd want a bit more than the 32KB mandated by DX11.
I think shared memory, under graphics pipeline configuration (i.e. VS-GS-PS etc.), is used to hold triangle attributes ready for just-in-time interpolation by the pixel shader.
But more importantly, Larrabee bins geometry into screen-space tiles. Seiler describes a tiled forward renderer as Larrabee doesn't attempt to Z-sort/cull triangles like a tiled deferred renderer does, instead relying upon a Z-buffer and un-ordered triangle rasterisation/pixel-shading.
So once pixel shading of a tile is started it doesn't stop until all triangles in that tile have been rasterised and shaded. ATI and NVidia GPUs don't do any such binning, so putting a tile into shared memory would only last a short while before it's evicted for another tile. This exact process (thrashing tiles from the render target into on-die cache) is done by the ROPs. ATI functional diagrams contain blocks called "colour buffer cache" and "z/stencil buffer cache". Each of these is an independent cache dedicated to the named buffer.
Jawed
They do call it out as being "expensive", although the relative tradeoffs in hardware have certainly shifted somewhat over time. Definitely can't call ignorance of the literature though
