Texture upload either doesn't happen, or is not reflected in subsequent sampling

[yanchith]

Description
Hello, this is the bug I mentioned on the wgpu matrix channel.

My intuition is that the bug is probably not on wgpu's side, unless missing
validations in wgpu allowed me to do something terrible, that was also missed by
the vulkan validation layers.

Bug description:

• A texture is being uploaded to the GPU semi-regularly, this is driven by user
  interaction and doesn't happen every frame. The upload happens via
  create_buffer_mapped and copy_buffer_to_texture.

• Once per frame, this texture (whatever its contents may be at
  that moment) is blitted onto another texture, which is, with
  some post-processing blitted onto the swapchain.

• The bug is, that the uploaded texture is stops being updates after some time.
  Subsequent transfers to that texture either don't
  change it, or those changes are not reflected later, when it is
  sampled. The texture has both TextureUsage::COPY_DST | TextureUsage::SAMPLED. I also manually checked the contents of that texture
  and the data I am uploading is correct.

To record traces, I've also tried wgpu-rs master branch on linux. The bug still
reproduces there, at least under linux.

Repro steps
Unfortunately can't provide a runnable example. But I am attaching a recorded trace + screenshots + png encoded textures I uploaded to webgpu. Look for label "UI_TEXTURE" in trace.ron.

Expected vs observed behavior
I expect to see on the screen the texture I upload to wgpu. Instead, I see a solid color - see screenshot in attachment.

Extra materials
Attached zipfile contains the trace, captures of the uploaded textures, and a sreenshot of the error.

Platform
I can reproduce on two machines. Everywhere else the bug doesn't manifest at
all. On the two machines I can reproduce with (at least) these configurations:

Machine 1

• wgpu 0.4 + Linux + Intel HD 630 + Vulkan
• wgpu 0.5 + Linux + Intel HD 630 + Vulkan
• wgpu 0.4 + Windows + Intel HD 630 + Vulkan
• wgpu 0.5 + Windows + Intel HD 630 + Vulkan
• wgpu 0.4 + Windows + NVIDIA GeForce GTX 1650 + Vulkan
• wgpu 0.5 + Windows + NVIDIA GeForce GTX 1650 + Vulkan

Machine 2 (I only had it borrowed for a limited time, so I could only test one configuration)

• wgpu 0.5 + Windows + NVIDIA GeForce GTX 1080 Ti + Vulkan

deios-texture-update-bug-repro.zip

[kvark]

This is such a lovely bug report ❤️ . Definitely one of the best I've seen. Thank you for taking time! Bonus 🏅 for using the new API tracing functionality :)

I'm looking into it. Just wanted to note something about this:

Actually, a local patch of that version had to be used for recording, because log::trace in allocator.rs in wgpu-core panicked on out-of-bounds.

This is quite worrying, please file a bug on it! We aren't supposed to panic in trace logging ever.

[kvark]

Here is what I found so far. The texture uploads work well as intended. In the last place the texture is used, XCode Metal capture shows the contents as:

The iffy part is that the render pass (taking that texture as a input) has it in both u_texture and u_mask_texture slots, and it produces the solid color on the output. I checked the issued bindings, and the capture shows that you are binding the same texture to these slots:

            SetPipeline(Id(0, 1, Metal)),
            SetBindGroup(
                index: 0,
                num_dynamic_offsets: 0,
                bind_group_id: Id(8, 1, Metal),
            ),
            SetBindGroup(
                index: 1,
                num_dynamic_offsets: 0,
                bind_group_id: Id(8, 1, Metal),
            ),

So my guess is - this is either your binding logic picking the wrong bind groups, or the shader doing something wrong when reading the texture. Nothing from our wgpu processing side appears wrong so far.

Edit: I'm unable to debug your shader due to gfx-rs/gfx#3254

[yanchith]

Thanks for investigating ❤️ Judging from the screenshot, the bug does not reproduce for you.

I checked the issued bindings, and the capture shows that you are binding the same texture to these slots

We indeed do bind the same texture there twice under some circumstances, but the shader only reads from one of these when this happens. I can imagine this is not a very good practice though, and will try changing it in our app. Should we potentially validate against this?

Also:

This is quite worrying, please file a bug on it! We aren't supposed to panic in trace logging ever.

Yes, I will!

[kvark]

Judging from the screenshot, the bug does not reproduce for you.

No, I believe the bug is reproduced. The screenshot shows the contents of the texture. But the actual rendered output of the render pass is all solid, which is not what you want, if I understand correctly.

Try playing with the shader, perhaps, and output the texture without any complex logic. It should show up, since I see the texture contents in the debugger. Then you'd be able to narrow down if some shader logic breaks it.

Should we potentially validate against this?

There is nothing wrong from our side, I just wanted to point out, checking if that's really what you intend to do.

[yanchith]

No, I believe the bug is reproduced. The screenshot shows the contents of the texture. But the actual rendered output of the render pass is all solid, which is not what you want, if I understand correctly.

Ah, I see. Yes!

Ok, I will play with it some more and post results here.

[yanchith]

Ok, managed to drill this down to the cause. As suspected, wgpu had nothing to do with it 🎉 . I think we can close this, but here's a short explanation if anyone is interested.

Your suggestion to simplify the shader really helped uncover the real issue. It wasn't in the shader at all, but rather in the window scale factors. The shader is doing some fluffy texture copying and is taking the original texture dimensions in consideration instead of stretching.

A C++ dependency we use internally multiplies sizes and positions by the current window's scale factor, but we have been feeding it the physical sizes and positions, which lead to the texture the C++ dependency gives us having sizes that are multiplied by the scale factor twice.

The solid color texture produced on the shader was actually an inner rectangle of the texture, by chance blank, because there is no UI there.

Thanks for the help!