Native unclipped depth on supported platforms

[JMS55]

Objective

• Fixes Use native depth clip control instead of manual DEPTH_CLAMP_ORTHO where possible #16078

Solution

• Rename things to clarify that we want unclipped depth for directional light shadow views, and need some way of disabling the GPU's builtin depth clipping
• Use DEPTH_CLIP_CONTROL instead of the fragment shader emulation on supported platforms
  • Pass only the clip position depth instead of the whole clip position between vertex->fragment shader (no idea if this helps performance or not, compiler might optimize it anyways)
• Meshlets
  • HW raster always uses DEPTH_CLIP_CONTROL since it targets a more limited set of platforms
  • SW raster was not handling DEPTH_CLAMP_ORTHO correctly, it ended up pretty much doing nothing.
  • This PR made me realize that SW raster technically should have depth clipping for all views that are not directional light shadows, but I decided not to bother writing it. I'm not sure that it ever matters in practice. If proven otherwise, I can add it.

Testing

• Did you test these changes? If so, how?
  • Lighting example. Both opaque (no fragment shader) and alpha masked geometry (fragment shader emulation) are working with depth_clip_control, and both work when it's turned off. Also tested meshlet example.
• Are there any parts that need more testing?
  • Performance. I can't figure out a good test scene.
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
  • Toggle depth_clip_control_supported in prepass/mod.rs line 323 to turn this PR on or off.
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?
  • Native

---

Migration Guide

• MeshPipelineKey::DEPTH_CLAMP_ORTHO is now MeshPipelineKey::UNCLIPPED_DEPTH_ORTHO
• The DEPTH_CLAMP_ORTHO shaderdef has been renamed to UNCLIPPED_DEPTH_ORTHO_EMULATION
• clip_position_unclamped: vec4<f32> is now unclipped_depth: f32

[pcwalton]

Awesome!

[JMS55]

Technically I think I should have a version of the meshlet software raster that does depth clipping for all other views besides directional light shadows, but I'm not 100% sure if this even matters in practice so I've elected to just ignore it for now.

[JMS55]

Ready for review. Please post perf tests, I was unable to find a good comparison. Also please double check that the fragment shader is actually omitted when the emulation is off, renderdoc was confusing when I tried to check.

[JMS55]

@superdump when we set the frag depth to the unclipped depth, should we be writing 1 / unclipped depth or something? Is what we have correct?

[superdump]

Running many_cubes --benchmark --shadows on M1 Max main (yellow) vs this PR (red):

This PR looks slightly slower. I did check that depth clip control was supported. Seems odd...

[JMS55]

:/ yeah that's what I saw... Confusing.

[Elabajaba]

Noticeably faster on the GPU for shadow passes, though overall framerate doesn't improve due to still being CPU bound.

Left: 2 runs without the PR. Right: 2 runs with the PR

I'd expect a bigger win on iGPUs and mobile GPUs where you're way more bandwidth limited than a 6800xt at 720p lol. Number of shaded pixels dropped from 68,743,094 to 17,371,373 according to radeon gpu profiler.

Tested on bistro in scene_viewer with vsync disabled, winit update modes set to continuous, depth prepass added to the camera, camera transform Transform::from_translation(Vec3::new(-17.654163, 2.798615, -6.699705)).with_rotation(Quat::from_slice(&[0.0038612718, -0.7603651, 0.0045205816, 0.6494687])),

[JMS55]

Ok, so it doesn't improve FPS because we're still CPU bound, but on scenes with a lot of shadow fragments, we are faster now. I think we're good to merge :)