Shader translation error, no function with name 'fwidth'

[Lisible]

When I run a program that renders with wgpu using my intel chipset with mesa driver, on an optimus laptop, I'm getting a crash at the shader compilation stage for a shader that uses the fwidth built-in function.

[2023-10-01T15:17:12Z ERROR wgpu_hal::gles::egl] GLES: [ShaderCompiler/Error] ID 1 : 0:38(20): error: no function with name 'fwidth'
[2023-10-01T15:17:12Z INFO  wgpu_hal::gles::device] 	Compiled shader NativeShader(11)
[2023-10-01T15:17:12Z ERROR wgpu::backend::direct] Shader translation error for stage ShaderStages(NONE | VERTEX): 0:38(20): error: no function with name 'fwidth'

[2023-10-01T15:17:12Z ERROR wgpu::backend::direct] Please report it to https://github.com/gfx-rs/naga
[2023-10-01T15:17:12Z ERROR wgpu::backend::direct] Handling wgpu errors as fatal by default

According to the wgpu_hal logs, this is using OpenGL ES 3.2 with Mesa 23.1.8, and the shader language version is OpenGL ES GLSL ES 3.20.
The version of naga used is 0.12.2, pulled from wgpu 0.16.1

According to the GLSL ES 3.20 spec, the fwidth function should be provided as a built-in function.

I'm not sure if this is an issue on naga's side or in mesa.

[evahop]

The spec also states that these functions are only available in fragment shaders, could that be applicable to your use case?

[Lisible]

In my case I'm using it in the fragment shader.

[evahop]

From the wgsl spec it looks like it can be implemented with abs(dpdx(e)) + abs(dpdy(e)).
You could try that as a temporary workaround (assuming the other derivative built-ins exist).

I'm curious if there's some extension we're missing, but nothing's jumping out immediately.

[Lisible]

Replacing the call to fwidth by abs(dpdx(e)) + abs(dpdy(e)) as you suggested, it now complains that there is no built-in functions dFdx and dFdy. So it looks like these don't exist either, at least in my configuration.

[evahop]

Maybe you could try enumerate_adapters to see if the laptop has something more capable.

[Lisible]

I certainly could, of course. I'm running my program with my nvidia gpu using prime-run with no issue.

But it was really just to understand why it would not work with the intel one with mesa.

[evahop]

Yeah, I don’t believe this is an issue with naga’s translation. I’m not familiar enough with mesa to definitively say that’s the problem. I would probably throw fwidth into one of their example programs to confirm.

[teoxoy]

@Lisible are you using the derivative functions in a separate function (not directly in the fragment entry-point)?

We are not culling functions that are not used by an entry-point.

I'm getting this error with glslangValidator -S vert test.glsl with a shader containing a function using derivative functions.

ERROR: 0:22: 'dFdx' : no matching overloaded function found 
ERROR: 0:22: '=' :  cannot convert from ' const float' to ' temp highp 4-component vector of float'
ERROR: 0:22: '' : compilation terminated 
ERROR: 3 compilation errors.  No code generated.

I think this makes sense given that GLSL only supports one entry-point per file.

[Lisible]

I'm indeed using it in a separate function, not the entry point.

I will try calling it in the entry point when I'll get back home.

[teoxoy]

#2531 should fix it, you could also give it a try.

[Lisible]

I will try calling it in the entry point when I'll get back home.

I confirm that this works.

Thank you for your help with that.