GPU: Avoid clears for non-simple depth values #16361
Conversation
|
Hm, I thought LEQUAL/GEQUAL were super common, is it really worth having a separate mode? |
|
Well, they're relatively common (as is rounding mode in CPU), but there are definitely plenty of games that just use -[Unknown] |
GPU/D3D11/GPU_D3D11.cpp
Outdated
| } else if (PSP_CoreParameter().compat.flags().PixelDepthRounding) { | ||
| // Use fragment rounding on desktop and GLES3, most accurate. | ||
| features |= GPU_ROUND_FRAGMENT_DEPTH_TO_16BIT; | ||
| features |= GPU_SCALE_DEPTH_FROM_24BIT_TO_16BIT; | ||
| } else if (PSP_CoreParameter().compat.flags().VertexDepthRounding) { | ||
| features |= GPU_ROUND_DEPTH_TO_16BIT; | ||
| features |= GPU_SCALE_DEPTH_FROM_24BIT_TO_16BIT; | ||
| } |
There was a problem hiding this comment.
So Pixel/Vertex depth rounding are now equivalent? Deserves a comment, and can collapse these two else if a bit. Same in some more places.
There was a problem hiding this comment.
Well, I'll just keep them different for now. I was worrying that we've made vertex shaders overly complex from that other driver bug (that turned out to be the switch on unsigned), and figured that the range scaling is probably both faster and less likely to cause equal mismatches.
But we can leave it just to pixel for now, and I'll leave vertex alone.
-[Unknown]
Some drivers don't round depth the same way for a clear vs for drawing, which can cause mismatches. We only do this if we see equals-style depth comparison funcs used in drawing.
In most cases, this will be a lot faster than pixel depth rounding, and may avoid more issues in vertex rounding.
See hrydgard#16015. Attempting to avoid a driver bug.
unknownbrackets
force-pushed
the
depth-equal
branch
from
6a0506a to
745d9ad
Compare
|
This broke Nayuta graphics using vulkan backend. Screenrecording_20221110_115829_org.ppsspp.ppsspp.mp4 |
|
Can you upload a frame dump of where it has a trail like that? -[Unknown] |
|
here we go |
See #12626 and #14223. This makes some related changes.
First, it avoids using a "true" clear when depth is not 0.0 or 1.0 if the game has ever used an equal comparison for depth. This avoids rounding inaccuracies between the clear and draw paths in drivers, i.e. such as in #12626. I'm not sure this fixes that bug, but I'm hopeful based on what's seen.
Note that this is conceptually similar to the "rebuilding jit with rounding mode checks", where we use the more optimal path if possible.
Next, because the above makes doing this safer, this also prefers a scaled depth range to in-shader depth rounding when 24-bit depth is used (practically always.) This should be significantly faster for games that need per-pixel rounding (i.e. #14223), although it probably makes the #16015 workaround less usable.
Because a scaled range will never use 0/1, this does also mean that rounded depth with equality will never use clears, which probably has a penalty. But it's probably made up for by not rounding in the shader.
As an attempt to improve the impact to #16015... I noticed multiple games in that list were using ineffective ALWAYS depth tests and tried forcing it off in that case. I'm not sure it'll help but it doesn't seem like a bad thing.
-[Unknown]