!fjjkgHFcwtkREywzfk:matrix.org

Naga Shader Translator

252 Members
v0.20.0!11 Servers

Load older messages


SenderMessageTime
3 Oct 2024
@jimb:mozilla.orgjimbSomething that's an S or M with high impact could probably be justified.16:34:40
7 Oct 2024
@schell:matrix.orgschellI just ran into this problem https://github.com/gfx-rs/wgpu/issues/4551 19:34:12
@schell:matrix.orgschellDoes the suggested fix still make sense? I'm wondering that, if it does, would we need to do a similar operation to the atomic type upgrade? Or is this actually easier than that? 19:36:49
@schell:matrix.orgschell * Does the suggested fix still make sense? I'm wondering that, if it does, would we need to do a similar operation as the atomic type upgrade? Or is this actually easier than that? 20:12:12
@schell:matrix.orgschellI think it would be easier than that, actually20:12:31
@schell:matrix.orgschellOof, I don't know. Any time we have to "change the type" of something in the spv frontend I fear it requires a type upgrade.20:52:37
8 Oct 2024
@schell:matrix.orgschellI've got a condidate PR for the issue above^ 20:02:01
@schell:matrix.orgschellBut the resulting module fails to validate with "Inappropriate sample or level-of-detail index for texel access"20:02:23
@schell:matrix.orgschell I'm not sure if it's that I've inserted the expressions incorrectly or if my shader is just wrong. Is it possible to textureLoad on a depth texture? 20:03:14
@schell:matrix.orgschell

Here's the resulting WGSL (if I don't validate):

struct type_6 {
    member: f32,
}

var<private> global: vec3<u32>;
@group(0) @binding(0) 
var<storage, read_write> global_1: type_6;
@group(0) @binding(1) 
var global_2: texture_depth_2d;

fn function() {
    let _e5 = global;
    let _e9 = textureLoad(global_2, vec2<u32>(_e5.x, _e5.y));
    global_1.member = vec4(_e9).x;
    return;
}

@compute @workgroup_size(32, 1, 1) 
fn culltest_copy_depth(@builtin(global_invocation_id) param: vec3<u32>) {
    global = param;
    function();
}
20:03:44
@schell:matrix.orgschell Seems like it doesn't like vec2<u32>(_e5.x, _e5.y)? 20:04:47
@schell:matrix.orgschell * I've got a candidate PR for the issue above^ 20:05:02
@schell:matrix.orgschell

This is transpiled from a rust-gpu shader here:

#[spirv(compute(threads(32)))]
pub fn test_copy_depth(
    #[spirv(descriptor_set = 0, binding = 0, storage_buffer)] depth: &mut f32,
    #[spirv(descriptor_set = 0, binding = 1)] depth_texture: &Image!(2D, type=f32, sampled=true, depth=true),
    #[spirv(global_invocation_id)] global_id: UVec3,
) {
    let fetched_depth: Vec4 = depth_texture.fetch(global_id.xy());
    *depth = fetched_depth.x;
}
20:06:39
@schell:matrix.orgschellThough, applying the same strategy to image sampling (as opposed to image load) works just fine. 20:20:09
@schell:matrix.orgschellOk, looks like that problem was on my side, I needed to specify the level of detail23:10:19
@schell:matrix.orgschellAnyway https://github.com/gfx-rs/wgpu/pull/6384 is ready to go :) 23:10:43
9 Oct 2024
@chyyran:matrix.orgchyyran

naga is choking on WGSL also produced by naga... am I being stupid here

    Shader 'fragment' parsing error: expected assignment or increment/decrement, found '_e795'
         ┌─ wgsl:2070:11
         │
    2070 │     const _e795: vec2<f32> = vec2(2f);
         │           ^^^^^ expected assignment or increment/decrement

🤔

only thing I could think of is i'm using trunk naga to generate wgsl, did the syntax change since wgpu 22?

03:07:30
@chyyran:matrix.orgchyyran * naga is choking on WGSL also produced by naga... am I being stupid here
Shader 'fragment' parsing error: expected assignment or increment/decrement, found '_e795'
┌─ wgsl:2070:11

2070 │ const _e795: vec2 = vec2(2f);
│ ^^^^^ expected assignment or increment/decrement
🤔
only thing I could think of is i'm using trunk naga to generate the input wgsl, did the syntax change since wgpu 22?
03:07:49
@chyyran:matrix.orgchyyran *

naga is choking on WGSL also produced by naga... am I being stupid here

```
🤔
only thing I could think of is i'm using trunk naga to generate the input wgsl, did the syntax change since wgpu 22?
03:08:15
@chyyran:matrix.orgchyyran *

naga is choking on WGSL also produced by naga... am I being stupid here

    Shader 'fragment' parsing error: expected assignment or increment/decrement, found '_e795'
         ┌─ wgsl:2070:11
         │
    2070 │     const _e795: vec2<f32> = vec2(2f);
         │           ^^^^^ expected assignment or increment/decrement


🤔
only thing I could think of is i'm using trunk naga to generate the input wgsl, did the syntax change since wgpu 22?

03:08:46
@chyyran:matrix.orgchyyranswitched everything to trunk wgpu and it works so I'm assuming it's a syntax update 🙃03:32:40
@cwfitzgerald:matrix.orgcwfitzgerald
In reply to @chyyran:matrix.org
switched everything to trunk wgpu and it works so I'm assuming it's a syntax update 🙃
If this is inside of a function, we only have recently supported const declarations Within functions
04:15:14
@chyyran:matrix.orgchyyranthat would make a lot of sense04:21:16
@chyyran:matrix.orgchyyran I was just testing to make sure my inverse polyfill pr wasn’t breaking anything 04:23:16
10 Oct 2024
@schell:matrix.orgschell teoxoy: https://github.com/gfx-rs/wgpu/pull/6384#issuecomment-2404464744 is ready to go :) 21:51:51
@chyyran:matrix.orgchyyranimage.png
Download image.png
22:30:16
@chyyran:matrix.orgchyyran jimb: regarding https://github.com/gfx-rs/wgpu/pull/6385#pullrequestreview-2361520591 is it valid to emit a function with a reserved prefix? I checked with shader playground before and got this error when feeding something to wgsl-in with a __ prefix 22:30:19
@chyyran:matrix.orgchyyran * jimb: regarding https://github.com/gfx-rs/wgpu/pull/6385#pullrequestreview-2361520591 is it valid to emit a function with a reserved prefix? I checked with shader playground before and got this error when feeding something to wgsl-in with a __ prefix 22:30:30
@chyyran:matrix.orgchyyran Unless it's fine to add an exception for it in wgsl-in 22:42:07
@jimb:mozilla.orgjimbNo, you're right, that's a good point. I'll reply in the issue23:07:43

There are no newer messages yet.


Back to Room ListRoom Version: 5