DICE released this presentation that talks about how their renderer uses tile-based deferred shading with DX11:

http://publications.dice.se/attachments/GDC11_DX11inBF3_Public.pptx

The tile-based approach starts on slide 10.

On slide 12 they say they use 1 thread per pixel, and 16x16 thread groups per tile. To process the entire screen, I assume they use the ID3D11DeviceContext::Dispatch() parameters to spawn a bunch of those 16x16 thread groups. For example, for a resolution of 1360x768, they'd call Dispatch( 85, 48, 1 ). Does that sound about right?

On slide 13 they have each thread group determine the min/max depth for its 16x16 pixel screen tile. This is done through groupshared data and interlocked instructions.

Slide 15 describes how they perform culling of the light list vs. the screen aligned bounding box established on slide 13. Instead of each thread in the 16x16 thread group processing a pixel, now each thread processes a light from the incoming light list and, if that light intersects the bounding box, that thread adds the light index to the group shared list of lights. At the end of this phase, each thread group has a list of lights that potentially intersects the pixels in that tile.

Slide 15 handles only point lights. What if we wanted to handle both point and spot lights? Two ideas come to mind. One is to expand struct Light to include additional parameters needed for spot lights. Another is to use two independent structures, one for point and the other for spot. In the first case, we continue to use a single for() loop and conditionally select which intersect test to use based on the light type. In the second case, we use two for() loops, first processing the point lights and then another for() loop to process the spot lights. The second approach feels like it should be more efficient than the first due to coherency between the threads in the thread group.

Slide 16 switches back to processing pixels. Each thread iterates through the list of lights potentially intersecting its bounding box and performs the lighting calculation for its pixel. This all makes sense. Is there further culling that should be performed at this stage? For example, would it be beneficial to test each pixel to determine whether it intersects the spot light cone? Or probably better to simply use a clamp instruction?

One thing not mentioned in the presentation is how they make the initial unculled list of lights available to the Compute Shader, other than that they use a StructuredBuffer for the light data and a Constant Buffer for the # lights. According to NVIDIA, if a Buffer is created as Dynamic, it resides in AGP memory all the time. You can lock it, update selective portions, and unlock it and yet nothing will get uploaded to the graphics card. When the shader reads from the buffer, only the needed data is uploaded at PCI speeds, but the entire buffer is never uploaded to video memory. In contrast, non-dynamic buffers reside in video memory. They can be updated with UpdateSubresource, in which case the data updated is copied to a temporary buffer in system memory and eventually uploaded to video memory before the shader needs it. The first method is slower for the graphics hardware (reading memory over PCI is slower than reading it from video memory), and the second method imposes more overhead on the CPU (from all that copying).

Since the unculled list of lights probably changes every frame, it's unclear which method would be faster. But it's easy to switch between the two methods, so once I get to that point, I'll try them both. My gut feel is that with so many threads accessing the light buffer, it's probably best to go with the UpdateSubresource method and have everything reside in video memory.

Hey,

If you want to see some actual code of a tile-based deferred renderer: Deferred rendering for current and future rendering pipelines by Andrew Lauritzen.

He dispatches as you mention. And he calculates, like dice probably does, a mini frustum for each tile (znear and zfar are the min and max values of the depth buffer of the tile) and culls the point lights via: point light sphere vs frustum. He doesn't do any (per pixel) culling after that.

It only uses point lights. And the way you are mentioning about how to include different type of lights is also the only way I can think of but I'm curious of other reactions.But yeah, I also have that same feeling like "wow, there is a lot of dynamic branching going on".

@Litheon - thanks for the link. This will really help out. In his code, he's using the Map/Unmap method and so his light data stays in host memory. Even so, he's able to render 1024 lights in around 6ms on my 450 GTS.

@Jason Z:
Wouldn't using UpdateSubresource() do the same thing as the staging buffer method, only with less implementation work? UpdateSubresource() copies the data to a temp buffer in host memory and then uploads that data to video memory before the shader executes. So either method performs the data copy / upload steps.

I have the 360 version of BF3. Great game BTW. Very pretty graphics.

Regarding pre-sorting the lights, pre-sort with respect to what? Do you mean pre-cull against the frustum? We're using Umbra 3 in our game and so it would be trivial to have Umbra cull out all non visible lights before I upload them to the card.

I'm forging ahead on my implementation of tile based CS lighting. One thing I ran into is that since the mini-frustum vs. light culling that the threads do is in view space, my light data (position and direction) needs to be in view space, too. In my game, all lights are stored in world space, so I could simply transform them to view space on the CPU as they're being written to the StructuredBuffer. I'm not too excited about doing this since our games tend to be CPU limited.

One idea that came to mind is that I can upload the light data in world space and have the CS transform them into view space. I'm currently using a StructuredBuffer. Could I change that to a RWStructuredBuffer so the CS can make a pass at the data and transform it in place, writing it back into the same buffer? Would there be any conflict with the game code on the CPU updating the buffer at the same time the CS is writing to it? I'd think not because the CPU would get a fresh buffer when it calls Map().

Since the work of transforming the lights can be distributed across the threads in the CS, there's no chance of conflict where two or more threads are trying to transform the same light.

I'm new to CS programming, so if there's a better way to do this, I'd love to hear about it!

Another thought is that I could have the CS transform the light from world space to view space just during the mini-frustum phase and then discard the transformed data, and do the lighting computations in world space. This would eliminate the need to store the view space data back to a buffer at all because it won't be needed again (I think).

Currently I store the worldLightPos and viewLightPos matrixes in 1 RWStructuredbuffer, and I transform them from world to view with a ComputeShader to the same RWStructuredBuffer. But I haven't measured the performance.

I don't think you will have conflicts with a Map/Unmap, but maybe the staging buffer is a good way to go. Then you have more control of what is allocated in the memory.


Please keep posting your results, it is an interesting read! 

I captured a quick video of my progress and put it up on YouTube. It's a cube being lit by 6,000 tiny moving point lights. It runs at 60 FPS on a GeForce 460 GTX. Sorry for the bad quality - I'll upload something better in the future. More info is in the description of the video.

Next step is implementing projected spot lights. But I won't be able to start that for another week.