write_texture to a subsection of a texture on the Dx12 backend without first writing to the whole texture appears to do nothing

[Imberflur]

Description
write_texture for a subsection of a texture appears to do nothing on the Dx12 backend unless the whole texture was first written to. (debugging to show that subsection writes work after writing to the whole texture not detailed here)

Repro steps
Apply diff to wgpu-rs and run cube example with WGPU_BACKEND=dx12
(let me know and I can create branches for this and future issues)

diff --git a/examples/cube/main.rs b/examples/cube/main.rs
index 983dde1..cb60e3e 100644
--- a/examples/cube/main.rs
+++ b/examples/cube/main.rs
@@ -207,7 +207,11 @@ impl framework::Example for Example {
                 bytes_per_row: Some(std::num::NonZeroU32::new(4 * size).unwrap()),
                 rows_per_image: None,
             },
-            texture_extent,
+            wgpu::Extent3d {
+                height: texture_extent.height / 2,
+                width: texture_extent.width / 2,
+                ..texture_extent
+            },
         );

         // Create other resources

Expected vs observed behavior
Expected (produced via Vulkan backend):

Observed:

Extra materials
none (let me know if an api trace is useful for this and I can get one)

Platform
Windows 10, wgpu-rs: 82b7068, GPU: AMD Radeon(TM) Vega 3 Graphics

[kvark]

@Imberflur thank you for filing!
I tested on "Intel Iris Graphics 550 (Dx12)", and the modified test case works as expected. Will try AMD next.

[kvark]

@Imberflur I was able to look at this on an AMD machine and reproduce reliably.

Bad news is - I haven't figured out if there is anything wrong going on. RenderDoc shows the temp buffer as full of zeroes (even though it's unaffected by the extent changes), so it doesn't help in the diagnosis...

Good news - wgpu needs to initialize all the texture resources anyway, so this will likely not show up at all once we get that logic implemented - #1102

[kvark]

I captured it in PIX, and interestingly, it shows the correct rendering in the analysis. That means Microsoft doesn't anticipate the driver behavior that AMD does, and the DX12 runtime validation doesn't see anything wrong either. So for now my conclusion is this being a driver bug.

I uploaded the code (adjusted to force DX12 and re-upload every frame) to https://github.com/kvark/wgpu-rs/tree/bug-dx12-texture-upload and filed a bug report using AMD tool. Unfortunately, it didn't give me any reference number to hold to...

There is still a chance I'm missing something, and we are doing things wrong, though. Any help investigating this is welcome!

[Imberflur]

@kvark thank you for looking into this! I'm not sure what aspects are left to investigate besides searching for Dx12 texture upload issues on AMD or investigating the Dx12 spec to see if things are being done correctly. Fortunately, it will be quite easy for me to work around this by just adding a temporary initialization for our atlas textures.

[rys]

I've filed this on the AMD side to get looked at here, thanks for the excellent repro @kvark!

[teoxoy]

Is this still an issue on newer driver versions?

[Imberflur]

I will try to test this soon.

[Imberflur]

updated driver to:

The issue still appears on wgpu 0.9 (I wasn't able to test the exact commit I listed above).

The issue doesn't appear on wgpu 0.10 (I tried the commit for 0.10.0 release as well as a few other commits) nor the latest git commit on trunk (12ee31d).

#1102 was implemented so the latest version should work even if the driver bug wasn't resolved (but I don't think this change was in wgpu 0.10?).

Regardless, this issue is at least probably no longer relevant for wgpu.

[cwfitzgerald]

Sounds good, closing.