Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wgpu-core: TextureClearRange does, in fact, track volume slices separately #2347

Closed
ElectronicRU opened this issue Jan 2, 2022 · 0 comments · Fixed by #2348
Closed

wgpu-core: TextureClearRange does, in fact, track volume slices separately #2347

ElectronicRU opened this issue Jan 2, 2022 · 0 comments · Fixed by #2348
Labels
area: correctness We're behaving incorrectly help required We need community help to make this happen. type: bug Something isn't working

Comments

@ElectronicRU
Copy link
Contributor

Description
When initializing 3D texture memory, WGPU generates a zero buffer copy to each depth level of the texture as if it were a layer.

Seems like this happens because texture tracker is initialized to have a separate layer for each depth_or_array_layers regardless of
texture dimensions.

Repro steps

  1. Make a 3D texture with more than one depth slice.
  2. Trigger initialization (I did it with copy_texture_to_texture).
  3. A boatload of validation errors.

Expected vs observed behavior
A load of errors telling that API tried to copy a buffer to texture layer where none are present.

Platform
Windows 10, wgpu 0.12.0 on Vulkan.

@cwfitzgerald cwfitzgerald added area: correctness We're behaving incorrectly help required We need community help to make this happen. type: bug Something isn't working labels Jan 3, 2022
cwfitzgerald pushed a commit that referenced this issue Oct 25, 2023
There are a few keywords like "pass" in HLSL that are actually case-insensitive for FXC. This can be disabled with strict mode, but even if you do that FXC will continue to give an error if you try to use them in identifiers (at all, with any casing).

This changes the namer code to escape these keywords even if the casing is different.

If you're wondering where I got the list from: I looked at the list of strings in D3DCompiler_47.dll.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: correctness We're behaving incorrectly help required We need community help to make this happen. type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants