2012288 - Reading/loading or sampling from a "2D array texture" seems to ignore the layer index

Status: ASSIGNED

(Core :: Graphics: WebGPU, defect, P2)

Description

[Ghadeer Abou-Saleh]

Attachment: Top cube is unexpected. Bottom one is expected.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

I opened the following page:

https://ghadeeras.github.io/pages/texture-2d-array

This page has a rather minimal code (toy.js) to run: 1) a compute shader that populates a 2D array texture such that red increases along its U axis, green increases along it V axis, and blue increases along its layer index. 2) a rendering shader that samples this texture mapping it to a cubic grid that is projected on a canvas element, such that U aligns with X, V aligns with Y, and the layers index aligns with Z.

Actual results:

The rendered cube has only shades of red/green mixture, suggesting that the samples are always coming from the first layer with index 0 (and with 0 blue). So the top cube in the attached image.

Expected results:

I should see a rotating cube with shades of red/green/blue mixtures, such that the blue component increases along the depth of the cube. See the bottom cube in the attached image.

Notes: 1. The only way to fix this currently is to either use Chrome or to change the WebGPU backend of Firefox to Vulkan. 2. This issue still exist in the nightly version of 149. This seems a regression of: https://bugzilla.mozilla.org/show_bug.cgi?id=1952976 because it also affects another demo in which a pipeline renders to a 2D-array texture.

Comment 1

[Sotaro Ikeda [:sotaro]]

:teoxoy, is this bug related to Bug 1952976?

Comment 2

[Teodor Tanasoaia [:teoxoy]]

I don't think this is related to Bug 1952976, the render pass in the example doesn't render to a slice of a 2d-array attachment.

Is this the problematic code? The call to textureSample always samples from 0?
https://github.com/ghadeeras/ghadeeras.github.io/blob/b928d214e04098ebe6f665020c4815bf769b39e7/src/texture-2d-array/toy.ts#L278

Comment 3

[Ghadeer Abou-Saleh]

The problematic code could indeed be the one you highlighted (i.e. during sampling):

https://github.com/ghadeeras/ghadeeras.github.io/blob/b928d214e04098ebe6f665020c4815bf769b39e7/src/texture-2d-array/toy.ts#L278

Or it could be during writing:

https://github.com/ghadeeras/ghadeeras.github.io/blob/b928d214e04098ebe6f665020c4815bf769b39e7/src/texture-2d-array/toy.ts#L335

The reason I believe it is related to Bug 1952976 is that I have another example that actually renders to a 2d-array slice that does not work on Firefox, but works on Chrome (again, unless I switch to a Vulkan backend). I did not share that example because it is not minimal and has lots of complicated code that is done my own way (not idiomatic). But if you want you could also navigate to:

https://ghadeeras.github.io/pages/path-tracing

This demo renders first to a 2d-array slice so that in a following shader it could average multiple frames (stacking) to reduce the number of samples per pixel per frame that is done during path-tracing. You will see that the demo works fine on Chrome, but displays a black screen in Firefox. If you navigate the 3D scene (with WASD or mouse dragging) you will see some frames, but they will freeze to (I think) the one noisy frame rendered at layer 0. In Chrome, the quality of the image will improve as it averages frames from other layers.

The rendering shader in this other example is:

https://github.com/ghadeeras/ghadeeras.github.io/blob/master/shaders/path-tracing.wgsl

The sampling is done here:

https://github.com/ghadeeras/ghadeeras.github.io/blob/master/shaders/stacker.wgsl#L69

If I find some time I could prepare a minimal example with rendering instead of using a storage texture.

Comment 4

[Ghadeer Abou-Saleh]

That said, if it is indeed an issue in how the texture is being sampled, then you're right, it would not matter how data ended up in the 2d-array texture (whether through rendering or writing in a compute pass).

Comment 5

[Ghadeer Abou-Saleh]

I tried to hardcode the last parameter of textureSample to be layers - 1 (i.e. the last layer), and I still get the same colors. So, I think you're right, the issue is more likely in sampling, not in writing. If it were only in writing I suppose I would get black everywhere.

Comment 6

[Teodor Tanasoaia [:teoxoy]]

Let us know if you managed to narrow it down; I briefly looked at the code and I didn't see anything obviously wrong. We also don't seem to have a similar issue reported over in the wgpu repo.

Comment 7

[Ghadeer Abou-Saleh]

To avoid misunderstanding, what I meant to say was that even if I sample from layer layers - 1 I still get red/green mixtures, and no blue. I would expect blue to be prominent in the last layer.

I did another experiment in which I only attached the last layer to the bind group using a texture view, and only then I managed to get the bluish mixtures. That is I changed line 132 as follows (in addition to hardcoding the layer to layers - 1 in the shader):

                resource: texture3D.createView({baseArrayLayer: 15, arrayLayerCount: 1, dimension: "2d-array"}),

This proves that there is no issue in writing to the texture, but there is an issue in reading back from an arbitrary layer.

Also texture copying shows that the last slice is populated with bluish colors.

Finally if I try textureLoad instead of textureSample, I get the same anomaly. So, it is not limited to sampling from 2d arrays. It is any reading from a 2d-array texture in a shader always gives me data from layer 0.

So, should I close this bug and open another one about reading from 2d-array textures? Or should I modify this bug's description?

Comment 8

[Ghadeer Abou-Saleh]

As for not having the same issue in wgpu, I wonder if it is related to the backend being chosen. This issue goes away if the backend is Vulkan. Could it be that wgpu chooses Vulkan by default, whereas on Windows, and in the user agent it is picking DirectX instead?

Comment 9

[Teodor Tanasoaia [:teoxoy]]

I think just renaming the issue would be fine.

As for not having the same issue in wgpu, I wonder if it is related to the backend being chosen. This issue goes away if the backend is Vulkan. Could it be that wgpu chooses Vulkan by default, whereas on Windows, and in the user agent it is picking DirectX instead?

That is probably why there isn't an open issue about it.

So, it is not limited to sampling from 2d arrays. It is any reading from a 2d-array texture in a shader always gives me data from layer 0.

It sounds like we should make sure that we plumb the nr of array layers of the texture view properly to the D3D12 backend.

Comment 10

[Ghadeer Abou-Saleh]

I renamed the issue.

Comment 11

[Andy Leiserson [:aleiserson]]

https://github.com/gfx-rs/wgpu/pull/9542 has a fix.