Skip to content

fix crash when rendering to a slice of a 3D texture

Erik Faye-Lund requested to merge d3d12-fix_texture3d_crash into msclc-d3d12

When we're rendering to a slice of a 3D texture apart from the first one, we pass a layer index that is non-zero to d3d12_transition_subresources_state(), because we have re-interpreted it as layered 2D resource for the purpose of the view.

But 3D textures doesn't have layers, and we end up using the non-zero layer-index to compute at sub-resource index that is out of range, ultimately leading to memory-corruption and random failures elsewhere.

While we're at it, let's also make sure that we trigger an assert in the future if we try to read outside of the array. Why the MSVC debug runtime doesn't notice this is beyond me, I'm used to getting asserts triggered for stuff like this there, but nothing happens apart from the memory corruption here.

This problem can be reproduced by running the spec@arb_framebuffer_object@fbo-generatemipmap-3d piglit, like so: %PIGLIT_DIR%\fbo-generatemipmap-3d.exe -auto -fbo

This fixes part of the same issue as !194 (closed) does, but I think this is a more appropriate fix. Instead of lying about the layer and then trying to fix that later, we avoid passing the wrong information down from the call-site. The call-site here is what knows about the view, so it has the best chance at avoiding confusion.

But I think there's one more detail to get right. Not sure if these need to be fixed right away, but: We still use a confusing mixture of "subresource_id" and "layer" in the early helpers here, I think. There's already a precedence for this in the code, but I think it would be better if we could find a clean way of disambiguating this.

Edited by Erik Faye-Lund

Merge request reports