Allow binding depth as 565 by going through depal #15859
Conversation
hrydgard
force-pushed
the
depal-depth-565
branch
2 times, most recently
from
33b1fb0 to
f18a61b
Compare
|
Rebased on main. |
hrydgard
force-pushed
the
depal-depth-565
branch
from
596cb06 to
6a8bb3c
Compare
|
This now works on all backends except D3D9 for some reason, but will debug that some other time. |
hrydgard
force-pushed
the
depal-depth-565
branch
from
2e742dd to
5f48ee9
Compare
|
I usually look at this for depth swizzle: http://hitmen.c02.at/files/yapspd/psp_doc/chap10.html#sec10.2 It does look like maybe it flips the chunks vertically... -[Unknown] |
|
Oh yeah, indeed does look like it. Still, to accurately track swizzle state through the pipeline to avoid the compat flag, we would have to detect that the game actually undoes it with a triangle mesh, without using the 6mb address trick in this case... Or it might mean that emulating the swizzle "accurately" (as seen from the game) might not be that hard.. Still I'm having problems figuring out where exactly we should apply it in that case. Need to think more about it.. |
|
Does this mean it's broken in the software renderer (since it doesn't do the swizzling)? Materializing the right swizzle in VRAM mirrors sounds annoying... -[Unknown] |
There was a problem hiding this comment.
Hm, one of my biggest dislikes with compat flags is they tend to make an assumption about the overall game. I wish we could either generalize the detection more or make it more specific, i.e. only when 565ing depth, and only with a high prim count or something. But I guess this game probably uses it throughout...
-[Unknown]
GPU/Common/Draw2D.cpp
Outdated
| if (!draw2DPipeline565ToDepthDeswizzle_) { | ||
| g_scale = renderScaleFactor_; | ||
| draw2DPipeline565ToDepthDeswizzle_ = Create2DPipeline(&GenerateDraw2D565ToDepthDeswizzleFs); | ||
| linearFilter = false; |
There was a problem hiding this comment.
Why is this forced to false only when we're creating? Shouldn't it either be outside this if or just what the caller set?
-[Unknown]
There was a problem hiding this comment.
Silly mistake, fixing. I don't think we should try to use any filtering in these at any time.
| BlitUsingRaster(src->fbo, 0.0f, 0.0f, src->renderWidth, src->renderHeight, dest->fbo, 0.0f, 0.0f, dest->renderWidth, dest->renderHeight, false, DRAW2D_565_TO_DEPTH, "565_to_depth"); | ||
|
|
||
| // Really hate to do this, but tracking the depth swizzle state across multiple | ||
| // copies is not easy. |
There was a problem hiding this comment.
I guess we could track it as a usage flag and forward it when we blit. Is it that it copies the swizzled depth via 565 (color -> color), and then textures that with the triangle mesh to deswizzle? Poor developer must've not known about the mirrors... or maybe they're slow somehow?
-[Unknown]
There was a problem hiding this comment.
I don't think there's any way the mirrors are slow, and ignorance would be strange since it uses them earlier in the frame IIRC..
But hm, if we always do the flip when converting depth to color when the bits aren't set... I'll work more on this tomorrow or Monday.
|
And yes, in the software renderer it's broken exactly the same as this without the swizzle. |
This is a partial fix for #6105 (Ratchet & Clank particles visible through things), but there's still weird glitchiness. There's a pass during rendering that scrambles the mini depth buffer by using a triangle mesh. I wonder if it's trying to simulate the swizzle? But it doesn't really look like it...
… :( Hopefully temporary flag...
…oesn't work on DX9 yet though.
hrydgard
force-pushed
the
depal-depth-565
branch
from
77c01b2 to
a11e7e1
Compare
|
I have some new thoughts on avoiding the swizzle compat flag, but will get this in as-is first, so people can start testing it. |
Fixes #6105
Details: #6105 (comment)
This is an attempt at a fix for #6105 (Ratchet & Clank particles visible through things).
But there's still weird glitchiness, if we don't apply a bit of deswizzling, same as seen with the software renderer. There's a pass during rendering that scrambles the mini depth buffer by using a triangle mesh. But it doesn't really look like a swizzle... It just flips portions of the image so that after downsacling, each set of 4 lines (at original resolution) is upside down. Maybe that's somehow the difference between depth swizzle and color swizzle?
Plus there's some horizontal stretch somewhere that's not quite right.Things left to fix:
Normally when games use color as depth they texture with a swizzle flag in the address but this doesn't, so it indeed seems like swizzle compensation. We undo it during color->depth conversion (a special version of the color->depth copy shader).
After conversion to depth, it looks like this:
This results in weird artifacts like this:
With the latest changes here that applies a deswizzle operation: