Jump to content

  • Log In with Google      Sign In   
  • Create Account

[DX11] Tile-based Deferred Shading in BF3 discussion


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#1 360GAMZ   Members   -  Reputation: 133

Like
2Likes
Like

Posted 15 December 2011 - 01:22 PM

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.

Sponsor:

#2 Litheon   Members   -  Reputation: 263

Like
0Likes
Like

Posted 15 December 2011 - 02:10 PM

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".

#3 Jason Z   Crossbones+   -  Reputation: 5324

Like
0Likes
Like

Posted 15 December 2011 - 03:53 PM

To get the light data into a GPU memory resource, you can upload the data into a staging buffer and then copy it to a default usage buffer - there shouldn't be any big issue with having to stream the light data into the buffer from AGP memory.

It does mention in their slides that they support the other light shapes, it just doesn't provide the sample code for it. I don't have a copy of the game, but I assume the shader code exists somewhere in the installation - so you might check that out if you have already purchased it.

One other thing that I would find interesting is to find out if there is any benefit to pre-sorting the lights on the CPU and then passing a semi-sorted listing of lights in the structured buffer. This would probably drastically cut down on the number of lights needed to be processed in each thread group, but at the expense of building the sorted light spatial data structure. However, if the structure is maintained from frame to frame, then it could be an overall win...

I think my engine needs a tile based renderer sample :)

#4 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 15 December 2011 - 04:02 PM

@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.

#5 Jason Z   Crossbones+   -  Reputation: 5324

Like
0Likes
Like

Posted 15 December 2011 - 04:43 PM

What I mean about the pre-sorting is that the mini-frustums for each tile is known before hand (since it is a function of the camera orientation and position). If the lights are already sorted in some spatial hierarchy, then it should be possible to determine fairly efficiently which lights intersect (or could potentially intersect) each tile. That would effectively reduce the amount of tests that each tile needs to do before the threads are even dispatched. The sorted data could be provided in some data structure (i.e. something in a raw byte address buffer) or perhaps in a number of structured buffers...

About the resource updating, it depends on how the destination buffer is being used. If you explicitly copy the data between resources yourself then you have a little more control over how the update occurs. If you can ensure that your staging buffer won't have any contention, then your copy should choose the fastest method available.

#6 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 16 December 2011 - 08:59 PM

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!

#7 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 16 December 2011 - 09:02 PM

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).

#8 Litheon   Members   -  Reputation: 263

Like
1Likes
Like

Posted 17 December 2011 - 05:05 AM

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! 

#9 Jason Z   Crossbones+   -  Reputation: 5324

Like
0Likes
Like

Posted 17 December 2011 - 12:30 PM

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.

Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?

#10 360GAMZ   Members   -  Reputation: 133

Like
1Likes
Like

Posted 19 December 2011 - 02:53 PM

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.

#11 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 21 December 2011 - 01:57 AM

1324119934[/url]' post='4894742']
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!


That's a really interesting idea. So you're saying that your light buffer has space for both the world and view positions, but the view position is placeholder until the shader writes the transformed data to it?


#12 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 21 December 2011 - 02:10 AM

1324146611[/url]' post='4894834']

1324090742[/url]' post='4894682']
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.

Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?


I think that should definitely work. Though, it would require 6 transformations instead of the 2 I'm currently doing: light to view space for culling and pixel position to world space for the lighting calc. Alternatively, I could do the lighting calc in view space, but I would have to transform the light to view space a 2nd time, so it's a wash. Unless I stored the transformed light for reuse in the lighting calc, but I believe 3 dot products is faster than a resource store + load.

#13 Jason Z   Crossbones+   -  Reputation: 5324

Like
0Likes
Like

Posted 22 December 2011 - 12:27 AM



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.

Why not convert the mini-frustums to world space instead? This would effectively require you to get the world space position and orientation of the camera, then you can generate your mini-frustums from that. That way your lights stay in world space, your mini-frustums are in world space, and no transformation is required on the CPU or GPU.

Would that work in your use case?


I think that should definitely work. Though, it would require 6 transformations instead of the 2 I'm currently doing: light to view space for culling and pixel position to world space for the lighting calc. Alternatively, I could do the lighting calc in view space, but I would have to transform the light to view space a 2nd time, so it's a wash. Unless I stored the transformed light for reuse in the lighting calc, but I believe 3 dot products is faster than a resource store + load.

Maybe I am not really understanding (sorry for beating a dead horse...) but if all of these are on your CPU side:

  • Light data is in world space
  • Frustum data is in view space
  • Pixel position (in view space?)
  • Lighting is carried out in view space


If all of that is true, then you should be able to convert the frustums to world space, reconstruct the world space pixel position instead of view position, and then carry out the lighting in world space. That would reduce the overall work needed on the GPU, while minimizing the work needed on the CPU (frustum data must be done on CPU). Am I seeing this correctly?




#14 Ardilla   Members   -  Reputation: 100

Like
0Likes
Like

Posted 03 January 2012 - 06:50 AM

Very interesting topic!

I am working on a deferred pipeline for PC. Since tile based technique has been implemented on X360, can anyone say me the advantages and disvantages of tile based over quad based deferred in DirecX 10??

Thank so much!

#15 360GAMZ   Members   -  Reputation: 133

Like
1Likes
Like

Posted 03 January 2012 - 10:28 PM

Ardilla, not sure about consoles, but on PC tile based has been superior from what I've experienced. Andrew Lauritzen has a paper and full demo with source code that allows you to play around with various methods including tile based vs. quad based:

http://visual-computing.intel-research.net/art/publications/deferred_rendering/

#16 MJP   Moderators   -  Reputation: 11761

Like
1Likes
Like

Posted 03 January 2012 - 11:13 PM

Well you still get the main benefit, which is that you can batch multiple lights while shading each pixel which saves you bandwidth (both from sampling the G-Buffer, and blending the lighting result). What you lose out on by using a pixel shader is shared memory, which prevents you from doing the per-tile culling directly in the shader in the manner used by Frostbite 2 and Andrew Lauritzen's demo. So you either have to find some other way to do the tile->light association on the GPU, or you have to do it on the CPU.

#17 Ardilla   Members   -  Reputation: 100

Like
0Likes
Like

Posted 04 January 2012 - 03:12 AM

mmm, interesting, Im going to implement a light volume technique in a first moment (I understand it better), and then I will try to implement the tile-based to see the performance difference Posted Image .

Thanks for the answers!

#18 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 04 January 2012 - 03:40 AM

I've run into a problem trying to render translucent objects into the scene after the deferred rendering has finished with the opaque objects.

Since a picture is worth a thousand words, here's my current DX11 rendering pipeline:

Deferred Rendering Pipeline Method 1 Fail


Since the translucent objects need to sort against the opaque scene, I want to reuse the depth buffer created during the deferred pass. However, the depth buffer is MSAA while the final render target is non-MSAA and so they can't be used together.

Here's one possible solution:

Deferred Rendering Pipeline Method 2


Here, the Lauritzen resolve shader is replaced with a shader that converts the flat StructuredBuffer into an MSAA render target (compute shaders cannot write to MSAA buffers, which is why Lauritzen uses a flat StructuredBuffer that holds all MSAA samples of the image). Since the lit render target is now MSAA, it can be used in conjunction with the MSAA depth buffer to render translucent objects. Finally, the ID3D11DeviceContext::ResolveSubresource() method is used to resolve the MSAA buffer to a non-MSAA buffer such as the back buffer.

Before I undertake this approach, I thought it would be a good idea to get feedback from the gurus here on this approach vs. any others that may come up. Here are a few questions:

1) Is it possible to wite such a shader to convert the flat buffer to a hardware compliant MSAA render target (meaning something the hardware can resolve to a non-MSAA buffer)? I'm not so sure this is possible since the flat buffer contains only the sample colors and no coverage mask.

2) If this method isn't possible, what are my alternatives? Can a depth buffer be resolved with ID3D11DeviceContext::ResolveSubresource()? If so, then Method 1 becomes much easier. [EDIT]: I've confirmed that a MSAA depth buffer cannot be resolved to non-MSAA.

#19 MJP   Moderators   -  Reputation: 11761

Like
1Likes
Like

Posted 04 January 2012 - 04:08 PM

The main problem with compositing is that you can't support arbitrary blending modes for your transparents. You can implement alpha blending and additive blending this way, but you couldn't also use other blending modes like multiply or screen. You can't automatically resolve a depth buffer, but you can do it manually with a pixel shader. Just sampling the first subsample and outputting it to SV_Depth should work well enough. Obviously you don't get MSAA with your transparents if you go this route.

To answer your first question, you can definitely write a pixel shader to convert from a structured buffer to an MSAA render target. To do it properly you'll need to run the pixel shader at per-sample frequency, which is done by taking SV_SampleIndex as an input to your shader. You can then use the pixel position + sample index to sample the proper value from the structured buffer, and then you just output it and it will get written to the appropriate subsample of the output texel. As far as D3D11 is concerned render targets only contain color data, not coverage. So you don't need to worry about that. There are exotic MSAA modes that decouple coverage and color (like Nvidia's CSAA), but you don't have direct access to that in D3D11 so you have to do it the standard way. As long as you still have your MSAA depth buffer, the transparent geometry will get rasterized and depth tested correctly.

#20 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 04 January 2012 - 04:57 PM

Thanks for the incredibly helpful reply, MJP!

...but you couldn't also use other blending modes like multiply or screen.


It's not clear to me why rendering translucent geo into a render target with the blend mode set to multiply wouldn't work.

Just sampling the first subsample and outputting it to SV_Depth should work well enough. Obviously you don't get MSAA with your transparents if you go this route.


So I bind the depth buffer as a SRV and run the pixel shader at per-pixel frequency by not specifying SV_SampleIndex as an input to the shader? Then, just simply read the depth texture and write it out to SV_Depth?

It sounds like this method (depth buffer resolve shader) is a better choice for our application. We draw a lot of translucent particles like smoke and so rendering that into a non-MSAA buffer sounds like less bandwidth. And since the particles tend to have smooth texture edges, MSAA probably wouldn't benefit us much.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS