0

I've just implemented deferred rendering/shading for the first time and I was surprised to see the big perfomance gap between forward and deferred rendering.

When I run my application with forward rendering I get a pretty decent frame rate while running in Release mode

FORWARD RENDERING enter image description here

However when I ran it with deferred rendering it gave me a rather surprising output

DEFERRED RENDERING enter image description here

I'm well aware of that deferred rendering is NOT something you coat an application with to make it go "faster". I consider it to be a performance optimization technique that can be optimized in a numerous ways and I understand that the technique has a larger memory footprint than forward rendering.

However...

I've currently got ONE point light in the scene and one hundred cubes created with hardware instancing. The light is moving back and forth on the Z-axis casting light on the cubes.

The problem is that the light is very laggy when moving. It's so laggy that the application doesn't register the keyboard input. Honestly, I was not prepared for this and I assume that I'm doing something terrible bad in my implementation.

So far I've changed the texture format on the gbuffers from DXGI_FORMAT_R32G32B32A32_FLOAT to DXGI_FORMAT_R16G16B16A16_FLOAT jsut to see if it had any visual impact but it did not.

Any suggestions? Thank you!

SIDE NOTE
I'm using the Visual Studio Graphics Diagnostics for debugging my DirectX applications

SvinSimpe
  • 850
  • 1
  • 12
  • 28
  • Is your question why does one run faster than the other, or why is it 'laggy'? And what exactly do you mean by laggy? – Adam Miles Jul 29 '15 at 16:33
  • My question is aimed at the laggy part. Are there any known performance side effects that one should know about when implementing deferred rendering? Like for instance 'Shadow Acne' and 'Peter Panning' is for shadow mapping. The light is not moving in a smooth motion along the axis as it is with forward rendering. It's a choppy motion just like when you're experience freeze lag on a game server. I'm guessing that whatever is causing the light to move that way is also causing the frame rate to drop. – SvinSimpe Jul 29 '15 at 16:44
  • But according to your screenshot the frame rate was over 600 frames per second. Does that not appear to be the case visually? – Adam Miles Jul 29 '15 at 16:46
  • Precisely! I'm guessing that the frame rate presented in the VS Graphics Diagnostics is pretty reliable as well. I also use the same functions in forward rendering when updating the buffer content. It looks so wierd to me. The light is moving some and then stops and then continue to move again. It's not moving in an identical pattern though. I have no idea :/ – SvinSimpe Jul 29 '15 at 17:08
  • Have you tried removing draw calls at particular stages of the render until the issue goes away? Perhaps try and narrow down the source of the problem to a particular Draw. It might also be worth getting a "second opinion" for whether the rendering has simply stopped for that period of if the update has just not simulated the light moving for a period. If you install the free version of Fraps and check the frame rate around the time it stalls, does it take a dive? – Adam Miles Jul 29 '15 at 17:23
  • I ran the different stages separately and forward rendering, geometry pass and deferred pass all produce around 4k fps on their own according to Fraps. However when combining two of them the frame rate races up and down in the interval ~420-1100 fps. So the frame rate is pretty lively when performing two passes per frame. I've taken my time uploading a short clip from how the scene looks so you can get a better picture of how the light behaves. As mentioned before, the light motion in the forward rendered scene is smooth. [This is the deferred](https://vid.me/tHon) – SvinSimpe Jul 29 '15 at 19:37

1 Answers1

1

Solved it!

I enabled the DirectX debug layer and I got a sea of D3D11 warnings

D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 1 is still bound on input! [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets[AndUnorderedAccessViews]: Forcing PS shader resource slot 1 to NULL. [ STATE_SETTING WARNING #7: DEVICE_PSSETSHADERRESOURCES_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 2 is still bound on input! [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets[AndUnorderedAccessViews]: Forcing PS shader resource slot 2 to NULL. [ STATE_SETTING WARNING #7: DEVICE_PSSETSHADERRESOURCES_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 3 is still bound on input! [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets[AndUnorderedAccessViews]: Forcing PS shader resource slot 3 to NULL. [ STATE_SETTING WARNING #7: DEVICE_PSSETSHADERRESOURCES_HAZARD]

So at the end of the render function i.e. after

mSwapChain->Present( 0, 0 );

I added

mDeviceContext->ClearState();

Just to reset the device context which sets all input/output resource slots to NULL as explained on MSDN

SvinSimpe
  • 850
  • 1
  • 12
  • 28