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

[naga] Allow dynamic indexing of array #6188

Open
wants to merge 7 commits into
base: trunk
Choose a base branch
from

Conversation

sagudev
Copy link
Contributor

@sagudev sagudev commented Aug 31, 2024

Connections
For arrays, at least, this fixes #4337, second commit is just gfx-rs/naga#723 ported to trunk.

Description
See commits and linked PR.

Testing
There are some new tests and I did CTS run in servo.

Checklist

  • Run cargo fmt.
  • Run cargo clippy. If applicable, add:
    • --target wasm32-unknown-unknown
    • --target wasm32-unknown-emscripten
  • Run cargo xtask test to run tests.
  • Add change to CHANGELOG.md. See simple instructions inside file.

@sagudev sagudev changed the title [naga] Allow dynamic indexing of array and matrix [naga] Allow dynamic indexing of array Sep 1, 2024
@sagudev
Copy link
Contributor Author

sagudev commented Sep 2, 2024

Servo's CTS run: https://github.com/sagudev/servo/actions/runs/10656885185/job/29537501039 (click view raw log, then find string Stable unexpected results, from there results start):
A lot of passes (do note that servo hit flakyl CRASH webgpu:shader,execution,expression,* due to servo/servo#31397) so I will only extract bad unexpected results:

TIMEOUT /_webgpu/webgpu/cts.https.html?q=webgpu:shader,execution,expression,call,builtin,textureSample:sampled_2d_coords:*
[2024-09-01T20:57:19Z ERROR wgpu_core::device::global] Device::create_shader_module error:
           Shader validation error:
              ┌─ :34:23
              │
         34 │           data[ndx] = textureLoad(tex, global_invocation_id.xy, mipLevel);
              │                                ^^^^^^^^^^^ naga::Expression [22]
       
 
    TIMEOUT [expected PASS] subtest: :format="bc1-rgba-unorm";sample_points="texel-centre"     
    NOTRUN [expected PASS] subtest: :format="bc1-rgba-unorm";sample_points="spiral"
    ...
TIMEOUT /_webgpu/webgpu/cts.https.html?q=webgpu:shader,execution,expression,call,builtin,textureSample:sampled_3d_coords:*
[2024-09-01T20:44:34Z ERROR wgpu_core::device::global] Device::create_shader_module error:
           Shader validation error:
              ┌─ :35:11
              │
         35 │           textureLoad(
              │           ^^^^^^^^^^^ naga::Expression [23]
    PASS [expected FAIL] subtest: :format="r8unorm";viewDimension="3d";sample_points="texel-centre"
    ...
    TIMEOUT [expected FAIL] subtest: :format="bc1-rgba-unorm";viewDimension="cube";sample_points="cube-edges" 
    NOTRUN [expected FAIL] subtest: :format="bc1-rgba-unorm";viewDimension="cube";sample_points="texel-centre"
    ...

@sagudev
Copy link
Contributor Author

sagudev commented Sep 2, 2024

First CTS failures is from https://github.com/gpuweb/cts/blob/9b30f7a02d172ce36d138c02614d0a5a1edbfa72/src/webgpu/shader/execution/expression/call/builtin/texture_utils.ts#L3318, because servo does not support GPUExternalTexture, second is just timeout because tests would need to be spillted more (or servo should be faster).

TL;DR all ok

@ErichDonGubler
Copy link
Member

Planning on reviewing this, and I heard @teoxoy also wanted to take a look. I'll consider this a learning experience for myself, since I'm still getting familiar with Naga, while @teoxoy would be the authoritative "LGTM". 🙂

@sagudev
Copy link
Contributor Author

sagudev commented Sep 4, 2024

I'll consider this a learning experience for myself, since I'm still getting familiar with Naga, while @teoxoy would be the authoritative "LGTM". 🙂

I am relatively new to naga too (my first commit to naga is 34bb9e4, which landed 5 days ago).

Copy link
Member

@ErichDonGubler ErichDonGubler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; let's see what @teoxoy has to say now. 😀

naga/tests/out/wgsl/access.wgsl Show resolved Hide resolved
@jimblandy
Copy link
Member

I think the sentence "Fixes #4337 for arrays" in the description of #6188 is confusing GitHub.

@jimblandy
Copy link
Member

Note that this PR must be squashed when merged.

self.function.internal_variables.push(variable);
id
}
// TODO: support `crate::TypeInner::Matrix`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't add TODO comments. Issues are easier to track, prioritize, and assign. Adding a comment that mentions an issue number is fine, if you like. (I know there are lots of other extant TODOs; the confusion is our fault.)

I'll fix this one myself.

Copy link
Member

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks really reasonable. Not approving yet because:

  • I have some more tweaks I want to push
  • I haven't actually looked over the test changes yet.
    I should be able to finish those tomorrow morning.

Comment on lines 153 to 159
let pointer_type_id = self.id_gen.next();
Instruction::type_pointer(
pointer_type_id,
spirv::StorageClass::Function,
container_type_id,
)
.to_words(&mut self.logical_layout.declarations);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out that, if the thing being indexed is a TypeInner::Array, that will never be a TypeResolution::Local, there will always be a Handle. So if we change this to expect a Handle<Type> instead of container_resolution, we can use get_pointer_id here as well.

I have a change that does this (and documents TypeResolution::Local a bit better) which I'll push to the branch tomorrow.

Comment on lines +187 to +192
block.body.push(Instruction::load(
result_type_id,
id,
element_pointer_id,
None,
));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think doing things this way means that, if we have something like:

fn (aaa: array<array<array<f32, 3>, 3> 3>, i: i32, j: i32, k: i32) -> f32 {
    return aaa[i][j][k];
}

then we'll end up spilling each intermediate array into its own SPIR-V variable, even though we could handle the access normally once we've spilled the outermost thing.

I don't have the wits at the moment to fix this. It's probably fine to address it in a follow-up PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for iterating! 😀

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang: WGSL WebGPU Shading Language naga Shader Translator
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

Support dynamic indexing of by-value matrices and arrays, per WGSL
4 participants