Skip to content
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

Merged
merged 55 commits into from Sep 21, 2020

Conversation

adrien-de-tocqueville
Copy link
Contributor

@adrien-de-tocqueville adrien-de-tocqueville commented May 4, 2020

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

  • Vertex density: Displays an overlay that highlights pixels containing multiple vertices. Helps finding models that need LODs.
    density


Testing status

Manual Tests: What did you do?

  • Opened test project + Run graphic tests locally
  • Built a player
  • Checked new UI names with UX convention
  • Tested UI multi-edition + Undo/Redo + Prefab overrides + Alignment in Preset
  • C# and shader warnings (supress shader cache to see them)
  • Checked new resources path for the reloader (in developer mode, you have a button at end of resources that check the paths)

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

Copy link
Contributor

@JMargevics JMargevics left a 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:
image
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).

@adrien-de-tocqueville
Copy link
Contributor Author

adrien-de-tocqueville commented May 13, 2020

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.

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

Base automatically changed from HDRP/staging to master May 19, 2020 23:34
@adrien-de-tocqueville adrien-de-tocqueville changed the base branch from master to HDRP/staging May 20, 2020 10:55
Copy link
Collaborator

@sebastienlagarde sebastienlagarde left a 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
Copy link
Collaborator

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 )

Copy link
Contributor

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");
Copy link
Collaborator

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

Copy link
Collaborator

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.

Copy link
Collaborator

@sebastienlagarde sebastienlagarde left a 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);
Copy link
Contributor

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?

Copy link
Collaborator

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

@sebastienlagarde
Copy link
Collaborator

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.

@adrien-de-tocqueville
Copy link
Contributor Author

Compilation error on metal

error: use of undeclared identifier 'input'
u_xlati6 = int(input.SV_PrimitiveID0) + 0x1;

Looks like a bug when the shader gets converted from HLSL to MSL.
SV_PrimitiveID is necessary for the quad overdraw debug mode only

@@ -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.
Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Collaborator

@JulienIgnace-Unity JulienIgnace-Unity left a 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?

@adrien-de-tocqueville
Copy link
Contributor Author

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

@JulienIgnace-Unity
Copy link
Collaborator

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
@adrien-de-tocqueville
Copy link
Contributor Author

adrien-de-tocqueville commented Sep 17, 2020

There is just one file for the DebugLightLayer

It's because I changed the script that sets the debug mode for the tests to be more consistent

@sebastienlagarde sebastienlagarde merged commit e8acbb2 into HDRP/staging Sep 21, 2020
@sebastienlagarde sebastienlagarde deleted the HDRP/vertex-density branch September 21, 2020 07:51
@sebastienlagarde sebastienlagarde mentioned this pull request Sep 22, 2020
6 tasks
@PaulDemeulenaere
Copy link
Contributor

PaulDemeulenaere commented Oct 6, 2020

Note, this change fails with PSSL as well : SV_PrimitiveID isn't available at fragment stage.
We are fixing this asap, see https://github.com/Unity-Technologies/Graphics/compare/HDRP/disable-quad-overdraw-ps4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
7 participants