Mixed render targets display, CryEngine, DX12 capture

[barycz]

Description

RenderDoc seems to incorrectly detect which texture is used as a render target when debugging a CryEngine demo application. When I run the sample FPS level there is a simple scene with a character. Most of the stuff is rendered using a deferred shading technique. If I capture the scene using PIX I can, for example, find a draw call that renders the gun: You can see in the OM section, there are 6 render targets with contents as I would expect. But if I try to capture the same frame and lookup the same draw call in RenderDoc, I see some unexpected textures bound there. It is worth mentioning, that the final image looks the same as when I run the application in Pix. I suspect RenderDoc from having more issues in the texture debug/display functionality, but I find this case easily reproducible.

Steps to reproduce

• Download CryEngine from https://www.cryengine.com/ (you have to register and download the launcher first, than download the engine)
• Create a FirstPersonShooter project from a template, open and export example.level to the game
• Switch the renderer to DX12, it can be done by adding "r_Driver": "DX12" to the console_variables section of your project file
• Run the game launcher using render doc: set executable path to C:\Program Files (x86)\Crytek\CRYENGINE Launcher\Crytek\CRYENGINE_5.6\bin\win_x64\GameLauncher.exe and add -project YourProject.cryproject argument
• hit F12 to capture the frame after the level loads (you have to move a bit to let the character draw the weapon)
• (optional) do the same using PIX to get the "correct" capture
• find for example the weapon draw call under SCENE->GRAPHICS_PIPELINE->GBUFFER->OPAQUE_VELOCITY, the render targets should be set to textures as shown in the pix capture

Environment

• RenderDoc version: git 455eddf3b49007a09969322a8fc921c0a4a82b54
• Operating System: Win 10 Pro
• Graphics API: DX12

Thank You!

[baldurk]

Since you're filing other related DX12 bug does this mean #1986 can be closed? Either if it's not a problem any more or if you don't have time to look into it further. Unless you're able to share a repro case or provide more information I can't look any further into that issue.

[baldurk]

This was related to a change I had to make a while ago to immediately read descriptors inside OMSetRenderTargets. Even though it requires a heap and descriptors the parameters are actually consumed immediately so the descriptors are pointless. Calls to CreateRenderTargetView() would be reflected but calls to CopyDescriptors*() would not, if they happened mid-capture before a OMSetRenderTargets call.