Open ghost opened 2 years ago
Nevermind about the "one-off" bug. What I think is happening here is that naga is transpiling my code to GLSL, and compiling the resultant GLSL fails. Thus, the error message seems to be from OpenGL—not naga—so the referenced line number is probably correct w.r.t the GLSL code.
To see what's actually happening, I'll try transpiling manually with the naga CLI and inspecting the GLSL output.
Here's the GLSL output:
#version 310 es
precision highp float;
precision highp int;
struct Output {
vec4 pos;
uint flags;
vec4 color;
vec2 tex_pos;
uvec2 pal_pos;
uint tex_page_x;
};
layout(location = 0) in uvec2 _p2vs_location0;
layout(location = 1) in uvec2 _p2vs_location1;
layout(location = 2) in uint _p2vs_location2;
layout(location = 3) in uvec2 _p2vs_location3;
layout(location = 4) in uvec2 _p2vs_location4;
layout(location = 0) flat out uint _vs2fs_location0;
layout(location = 1) smooth out vec4 _vs2fs_location1;
layout(location = 2) smooth out vec2 _vs2fs_location2;
layout(location = 3) flat out uvec2 _vs2fs_location3;
layout(location = 4) flat out uint _vs2fs_location4;
float make_tex_coord(uint coord, float max) {
return (float(coord) / max);
}
vec2 make_tex_pos(uvec2 pos_1, vec2 bounds) {
float _e4 = make_tex_coord(pos_1.x, bounds.x);
float _e7 = make_tex_coord(pos_1.y, bounds.y);
return vec2(_e4, _e7);
}
float make_ndc(uint coord_1, float max_1) {
float _e3 = make_tex_coord(coord_1, max_1);
return ((2.0 * _e3) - 1.0);
}
void main() {
uvec2 pos = _p2vs_location0;
uvec2 packed = _p2vs_location1;
uint color = _p2vs_location2;
uvec2 tex_pos = _p2vs_location3;
uvec2 pal_pos = _p2vs_location4;
Output out_ = Output(vec4(0.0), 0u, vec4(0.0), vec2(0.0), uvec2(0u), 0u);
vec2 vram_bounds = vec2(1024.0, 512.0);
float _e12 = make_ndc(pos.x, vram_bounds.x);
float _e15 = make_ndc(pos.y, vram_bounds.y);
out_.pos = vec4(_e12, (_e15 * -1.0), 0.0, 1.0);
out_.flags = packed.x;
out_.color = unpackUnorm4x8(color);
out_.tex_pos = vec2(tex_pos);
out_.pal_pos = pal_pos;
out_.tex_page_x = packed.y;
Output _e30 = out_;
gl_Position = _e30.pos;
_vs2fs_location0 = _e30.flags;
_vs2fs_location1 = _e30.color;
_vs2fs_location2 = _e30.tex_pos;
_vs2fs_location3 = _e30.pal_pos;
_vs2fs_location4 = _e30.tex_page_x;
gl_Position.yz = vec2(-gl_Position.y, gl_Position.z * 2.0 - gl_Position.w);
return;
}
Line 52 is out_.color = unpackUnorm4x8(color);
.
The code looks perfectly fine and glslangValidator
agrees, can we get some more information about the platform you're trying to run this in, and can you also test if it happens in others?
Hello, same problem here, I use wgpu and I target wasm, so WebGL.
The code looks perfectly fine and
glslangValidator
agrees, can we get some more information about the platform you're trying to run this in, and can you also test if it happens in others?
Sorry; I forgot to respond. Yes, I also encountered this while targeting WASM. I will look at this later today.
Isn't the actual issue here that OpenGL ES 3.0 / WebGL2 flavored GLSL doesn't have unpackUnorm4x8
and friends?
According to this they are introduced in 4.00 whereas, ES3/WebGL2 are based on 3.30
https://registry.khronos.org/OpenGL-Refpages/gl4/html/unpackUnorm.xhtml
(EDITS: Had some misconceptions about shader & webgl version matching)
@Wumpf I'm able to use unpack2x16unorm
and unpack2x16snorm
despite the Kronos page showing them as not in 3.3. Only unpack4x8unorm
and unpack4x8snorm
give the error
packUnorm4x8
packSnorm4x8
unpackUnorm4x8
unpackSnorm4x8
are only available starting with GLSL ES 3.10, so WebGL 2 won't have these.
We should error in this case ourselves to avoid confusion.
Links
https://registry.khronos.org/OpenGL/specs/es/3.0/GLSL_ES_Specification_3.00.pdf https://registry.khronos.org/OpenGL/specs/es/3.1/GLSL_ES_Specification_3.10.pdf
Shouldn't we polyfill them, these are already some of the ones that we polyfill for hlsl, and they're trivially polyfillable.
Just for reference I'm having a similar issue trying to use extractbits
I get the error message 'bitfieldExtract' : no matching overloaded function found
when targeting wasm (it works fine otherwise).
I imagine this would be easy to polyfill.
Hi!
On wgpu 0.13 (naga 0.9), I receive the following panic message:
Here's the offending code:
...of which line 52 is
out.tex_pos = vec2<f32>(tex_pos);
. That doesn't seem to be where the error is, though. (One-off bug?) Line 51 readsout.color = unpack4x8unorm(color);
, which is where I think the error arises. I think my code is correct according to the spec, though;color
is au32
, andout.color
is avec4<f32>
, which matches theunpack4x8unorm
function signature.For what it's worth, my shader code was previously validated correctly on wgpu 0.12 (naga 0.8).