lee/renderdoc
1
0
Fork 0
mirror of https://github.com/baldurk/renderdoc.git synced 2026-08-28 01:16:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

As a hack for now, don't save/restore D32F_S8 texture data

Browse Source 
* On nvidia it seems that doing glCopyImageSubData() on a D32F_S8 texture
  can cause serious problems, so ignore it for now. We can generally get
  away with it, as usually the only depth buffer in this format is the
  'main' depth buffer, which isn't used frame-to-frame.
This commit is contained in:
baldurk
2014-12-05 09:28:34 +00:00
parent 637232af14
commit 9561f88fd5
3 changed files with 23 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
renderdoc/driver/gl/gl_common.cpp
+3
View File
@@ -155,6 +155,9 @@ void DoVendorChecks(const GLHookSet &gl)
gl.glDeleteTextures(1, &dummy);
}
// don't have a test for this, just have to enable it all the time, for now.
ExtensionSupport::VendorChecks[VendorCheck_NV_avoid_D32S8_copy] = true;
}
bool ExtensionSupported(ExtensionCheckEnum ext)
renderdoc/driver/gl/gl_common.h
+1
View File
@@ -104,6 +104,7 @@ enum VendorCheckEnum
{
VendorCheck_AMD_vertex_buffer_query,
VendorCheck_EXT_compressed_cube_size,
VendorCheck_NV_avoid_D32S8_copy,
VendorCheck_Count,
};
bool VendorCheck(VendorCheckEnum ext);
renderdoc/driver/gl/gl_manager.cpp
+19 -3
View File
@@ -265,7 +265,15 @@ bool GLResourceManager::Prepare_InitialState(GLResource res)
if(details.curType == eGL_TEXTURE_CUBE_MAP)
d *= 6;
gl.glCopyImageSubData(res.name, details.curType, i, 0, 0, 0, tex, details.curType, i, 0, 0, 0, w, h, d);
// it seems like everything explodes if I do glCopyImageSubData on a D32F_S8 texture - in-program the overlay
// gets corrupted as one UBO seems to not provide data anymore until it's "refreshed". It seems like a driver bug,
// nvidia specific.
// In most cases a program isn't going to rely on the contents of a depth-stencil buffer (shadow maps that it might
// require would be depth-only formatted).
if(details.internalFormat == eGL_DEPTH32F_STENCIL8 && VendorCheck(VendorCheck_NV_avoid_D32S8_copy))
RDCDEBUG("Not fetching initial contents of D32F_S8 texture");
else
gl.glCopyImageSubData(res.name, details.curType, i, 0, 0, 0, tex, details.curType, i, 0, 0, 0, w, h, d);
}
gl.glTextureParameterivEXT(res.name, details.curType, eGL_TEXTURE_MAX_LEVEL, (GLint *)&state->maxLevel);
@@ -871,8 +879,16 @@ void GLResourceManager::Apply_InitialState(GLResource live, InitialContentData i
if(details.curType == eGL_TEXTURE_CUBE_MAP)
d *= 6;
gl.glCopyImageSubData(tex, details.curType, i, 0, 0, 0, live.name, details.curType, i, 0, 0, 0, w, h, d);
// it seems like everything explodes if I do glCopyImageSubData on a D32F_S8 texture - on replay loads of things
// get heavily corrupted - probably the same as the problems we get in-program, but magnified. It seems like a driver bug,
// nvidia specific.
// In most cases a program isn't going to rely on the contents of a depth-stencil buffer (shadow maps that it might
// require would be depth-only formatted).
if(details.internalFormat == eGL_DEPTH32F_STENCIL8 && VendorCheck(VendorCheck_NV_avoid_D32S8_copy))
RDCDEBUG("Not fetching initial contents of D32F_S8 texture");
else
gl.glCopyImageSubData(tex, details.curType, i, 0, 0, 0, live.name, details.curType, i, 0, 0, 0, w, h, d);
}
TextureStateInitialData *state = (TextureStateInitialData *)initial.blob;