Implement texturing from depth buffers (Vulkan only so far) #13262
Conversation
|
|
|
While totally out of the scope of this PR, can this path be used to get depth buffer in post processing shader eventually? |
|
@iota That can be done entirely separately, at least for games where the depth buffer is easily possible to associate with the buffer being presented (which excludes GTA for example where the present buffer isn't the main one, but a different stretched one). Please create an issue and I might get around to it one day... (EDIT: Actually some this stuff will be handy for that). |
|
Note to self, it's the second commit: "Vulkan/generic: Initial prep for depth texturing" (87b41cf) that breaks some games. I think I'll actually try to get the first two commits in first separately, testing carefully, before bringing in the rest. |
hrydgard
force-pushed
the
depth-texturing
branch
from
99aeceb
to
ba0d04a
Compare
|
Merged that and rebased on master. Should be working fine now, at least for Katamari. |
| textureCache_->NotifyFramebuffer(v->fb_address, v, NOTIFY_FB_DESTROYED); | ||
| // Notify the texture cache of both the color and depth buffers. | ||
| textureCache_->NotifyFramebuffer(v->fb_address, v, NOTIFY_FB_DESTROYED, NOTIFY_FB_COLOR); | ||
| textureCache_->NotifyFramebuffer(v->z_address, v, NOTIFY_FB_DESTROYED, NOTIFY_FB_DEPTH); |
There was a problem hiding this comment.
Hm. What if two framebufs use the same z address? Do/should we destroy?
It's definitely going to be common that we decimate a temp buf that uses the same depth buf as a normal color buf.
-[Unknown]
There was a problem hiding this comment.
Yeah that's a good question... Although it'll soon repair itself anyway if that happens. This just notifies the texture cache that it should forget about a framebuffer/texture association, so as soon as it's needed again, it'll be back.
| VkImageView fbo = (VkImageView)draw_->GetNativeObject(Draw::NativeObject::BOUND_TEXTURE0_IMAGEVIEW); | ||
|
|
||
| VkDescriptorSet descSet = vulkan2D_->GetDescriptorSet(fbo, samplerNearest_, clutTexture->GetImageView(), samplerNearest_); | ||
| VulkanRenderManager *renderManager = (VulkanRenderManager *)draw_->GetNativeObject(Draw::NativeObject::RENDER_MANAGER); | ||
| renderManager->BindPipeline(depalShader->pipeline); | ||
|
|
||
| if (depth) { | ||
| DepthScaleFactors scaleFactors = GetDepthScaleFactors(); |
There was a problem hiding this comment.
With accurate depth off, we actually deform the stored depth (it incorrectly depends on the depth viewport parameters when drawing - much like the XY viewport problem), which might cause problems for depth texturing. I think accurate depth is always on for Vulkan, though.
-[Unknown]
There was a problem hiding this comment.
Yeah we really need to get away from the stored depth being dependent on the viewport.. If we distort the viewport Z and the projection matrix together we should be able to get consistent results in the depth buffer while choosing how the clip happens, right?
There was a problem hiding this comment.
Well, accurate depth already does it "right". It basically does as you describe, but also tries to buffer things to make depth clamp scenarios fail less often. If we didn't distort depth, we'd have the same cases of depth going wrong that accurate depth has.
For example, that game where it uses a crazy depth scale (like a million), without incorrectly deforming the depth and without clamping, won't draw. That's why it seems like accurate depth is "wrong" there, only because clamping isn't working and the deformed depth path is accidentally working.
-[Unknown]
See #13256 , this should fix some of them.
Uses the old depal path, meaning we make a copy of the depth buffer but converted through a CLUT, then texture using that. Can be optimized more later to use direct CLUT lookups during texturing - but can be tricky if that depth buffer is currently bound!
Verified that it fixes the fog in Me and My Kamari, so helps #6411 (but just in Vulkan, so not closing):
Before:
After:
