New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vertex density & quad overdraw debug modes #353
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! PR looks good. I've checked both modes and both work as expected. Will approve (more info in favro card), but there are a few nitpicks from my side:
With Max Vertex Density <5 render mode gives inconsistent results. You can see that some vertices are assigned random colors while having a homogeneous wireframe. According to Adrien these are shader shenanigans, where GPU can recalculate random vertices.
Sliders should have tooltips as it is a bit unclear what they mean currently. Also from my experience sliders range from 0 to 2048 but "working" area was 0-100. Getting density right on the smaller object required manual editing of smaller number (2-10).
Small proposal:
To have a legend displayed in scene view, where it explains which color means which density (teal - 1 overdraw, red - 10 overdraws etc).
To be precise, I don't think that's random, that depends on the order of vertices in the model. It may show that reordering the vertices can lead to fewer vertex shader execution |
...ty.render-pipelines.high-definition/Runtime/RenderPipeline/ShaderPass/ShaderPassForward.hlsl
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So overall the PR is good, however I am worried by the extra memory and the extra slowness we will introduce on all the debug mode. We need to add a separate debug fullscreen pass that can be stripper and If users don't implement it, then it isn't an issue. We will discuss with with Julien and we should allocated debug memory only if required.
Now allocates one fullscreen uav instead of three
@@ -60,6 +60,9 @@ PackedVaryingsToPS VertTesselation(VaryingsToDS input) | |||
#include "Packages/com.unity.render-pipelines.high-definition/Runtime/RenderPipeline/ShaderPass/TessellationShare.hlsl" | |||
#endif | |||
|
|||
#if defined(DEBUG_DISPLAY) && !defined(_DEPTHOFFSET_ON) | |||
[earlydepthstencil] // quad overshading debug mode write to UAVs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know if attribute really work with guarded define - i.e arent they always apply even if there is guard ?
(poking @JulienIgnace-Unity / @FrancescoC-unity )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gaenerally the preprocessor is run before the attributes are evaluated for compilation (made small example with [branch] here http://shader-playground.timjones.io/82ad51ba693770094363e31f8b3bafe6 you can see in the DXC output how the branch contains the hint or not depending on the define value), so I think this should work fine, though never tried myself with forcing early depth stencil.
@@ -113,6 +116,8 @@ public void InitSharedBuffers(GBufferManager gbufferManager, RenderPipelineSetti | |||
// In case of deferred, we must be in sync with NormalBuffer.hlsl and lit.hlsl files and setup the correct buffers | |||
m_NormalRT = gbufferManager.GetNormalBuffer(0); // Normal + Roughness | |||
} | |||
|
|||
m_DebugDisplayUAV = RTHandles.Alloc(Vector2.one, TextureXR.slices, colorFormat: GraphicsFormat.R32_UInt, dimension: TextureXR.dimension, enableRandomWrite: true, useDynamicScale: true, name: "DebugDisplayUAV"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JulienIgnace-Unity we really need to do a pass on memory (note poking you also for render graph).
Currently we allocate a lot of memory even if we don't used thing, I know render graph can help here. But right now situation is still not good.
For the memory above for example 1) we shouldn't allocated in release or if we don't require debug, 2) we could reuse m_ContactShadowBuffer memory (which shouldn't be allocated if we disble shadow).
We will still merge this PR with this, but we really need to do a better memory management
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed but the question is: Do we want to spend time now doing this for the current code path are should we "just" wait for Render Graph to be enabled by default? Since we target Render Graph for the end of the month I'd say we wait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Waiting for a comment of Julien / Francesco about the #define on early stencil, otherwise it is ok.
But we will need to do a pass on memory allocation later. Situation isn't good.
// These modes are exclusive so we make only one fullscreen allocation for both. | ||
// For vertex density, it stores the number of vertex projected in each pixel. | ||
// For quad overdraw, each 2x2 quad of the UAV contains the overdraw count in top-left pixel and the locked quad in the bottom-right pixel. The two other pixels of the quad are unused. | ||
RW_TEXTURE2D_X(uint, _DebugDisplayUAV) :register(u2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sebastienlagarde I don't remember the details of our platforms implementation, but for the explicit registers in the uav did it need to be starting from after render target count or it is fine as soon as the register is after the render target count?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I have think about that as well, guess the code may not work on PS4.
on PS4 we will need to bing on 2 + number of RT allocated. We will check in a second time (I tracked this).
com.unity.render-pipelines.high-definition/Runtime/Material/SharedRTManager.cs
Outdated
Show resolved
Hide resolved
Note: not sure yet but the PR could affect Vulkan (guess this could be related to the early stencil?). I have re-run vulkan to be sure. |
Compilation error on metal
Looks like a bug when the shader gets converted from HLSL to MSL. |
Bug when accessing ShaderVariablesDebugDisplay cbuffer in tessellation stage
com.unity.render-pipelines.high-definition/Runtime/RenderPipeline/ShaderPass/VertMesh.hlsl
Outdated
Show resolved
Hide resolved
@@ -112,6 +112,11 @@ For more information, see the Lighting panel section in the [HDRP debug window]( | |||
|
|||
The Render Pipeline Debug window now has a new Volume panel which you can use to visualize the Volume components that affect a specific Camera. For each Volume that contributes to the final interpolated value, this panel shows the value of each property and whether or not it is overridden. It also calculates the Volume's influence percentage using the Volume's weight and blend distance. For more information, see the Volume panel section in the [HDRP debug window](Render-Pipeline-Debug-Window.md#VolumePanel). | |||
|
|||
#### Quad Overdraw and Vertex Density | |||
|
|||
Quad Overdraw highlights GPU quads running multiple fragment shaders, which is mainly caused by small or thin triangles while Vertex Density displays pixels running multiple vertex shaders. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add that it is not supported on metal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's already there in the line under
com.unity.render-pipelines.high-definition/Runtime/Debug/DebugDisplay.cs
Outdated
Show resolved
Hide resolved
com.unity.render-pipelines.high-definition/Runtime/RenderPipeline/HDRenderPipeline.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RenderFullScreenDebug needs to be static. Otherwise lgtm.
Is it expected that we have so many scenes, screenshots and prefab modified? Should this change any test at all?
There are two new tests but nothing else have been modified |
My bad, did not see most of them are in the new scenes. There is just one file for the DebugLightLayer scene then that should probably not be changed (probably not a big deal) |
lambda to static; fix with msaa
It's because I changed the script that sets the debug mode for the tests to be more consistent |
Note, this change fails with PSSL as well : SV_PrimitiveID isn't available at fragment stage. |
Purpose of this PR
This PR is adding two fullscreen debug modes in rendering pannel (not available on mac):
Quad Overdraw: Displays an overlay that highlights pixels running multiple fragment shaders.
Vertex density: Displays an overlay that highlights pixels containing multiple vertices. Helps finding models that need LODs.
Testing status
Manual Tests: What did you do?
Yamato: (Select your branch):
https://yamato.cds.internal.unity3d.com/jobs/902-Graphics/tree/HDRP%252Fvertex-density
Adds two graphics tests (3004 for quad overdraw & 3005 for vertex density) which have all standard and SG materials variations