| Summary: | interpolateAtSample check for input parameter is too strict | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | freedesktop |
| Component: | glsl-compiler | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | dark_sylinc |
| Version: | 17.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Sorry, copy/paste error, the first two lines are from another unrelated error. The correct error message is just this part:
0:18(33): error: parameter `interpolant` must be a shader input
0:18(6): error: no matching function for call to `length(error)'; candidates are:
0:18(6): error: float length(float)
0:18(6): error: float length(vec2)
0:18(6): error: float length(vec3)
0:18(6): error: float length(vec4)
0:18(6): error: double length(double)
0:18(6): error: double length(dvec2)
0:18(6): error: double length(dvec3)
0:18(6): error: double length(dvec4)
0:18(6): error: operands to relational operators must be scalar and numeric
0:18(6): error: if-statement condition must be scalar boolean
Thanks for the report. It does indeed look like this should be valid GLSL. I'm looking into it. Thanks a lot, couldn't have wished for another person to look into this :) +1 to this bug.
I just hit it after our refactor allowed our OpenGL backend to use more advanced MSAA functionalities.
Our code in question (heavily cut):
in block
{
flat uint drawId;
vec3 pos;
vec3 normal;
vec2 uv0;
vec4 posL0;
vec4 posL1;
vec4 posL2;
float depth;
float2 zwDepth;
} inPs;
vec2 pixelDepthZW;
pixelDepthZW = interpolateAtSample( inPs.zwDepth, 0 );
Mesa complains this is invalid (error: parameter `interpolant` must be a shader input), though to the best of my knowledge, it should be. AMD Windows drivers accept this fine, Windows propietary drivers only complain if I write interpolateAtSample( inPs.zwDepth.y, 0 ) which I was surprised to learn the spec kind of disallows it.
I'm glad someone already reported it.
I'm using git 57c8ead0cd
Thanks for the reminder. There were some related spec issues that we cleared up with the GL and ES working groups, but I have a set of patches that is almost ready to go in. Finally fixed in master, commit ca63a5ed3e9efb2bd645b425f7393089f4e132a6. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
The following code snippet fails on Mesa 17.0.3 with the following error: in GeometryToPixel { vec3 color; vec2 uv; } gs2ps; out vec4 Color; void main () { Color = vec4(gs2ps.color, 1); if (length(interpolateAtSample(gs2ps.uv, gl_SampleID))>1) { discard; } } This is the error: 0:10(1): error: if a fragment input is (or contains) an integer, then it must be qualified with 'flat' 0:10(8): error: `gl_SampleID' redeclared 0:18(33): error: parameter `interpolant` must be a shader input 0:18(6): error: no matching function for call to `length(error)'; candidates are: 0:18(6): error: float length(float) 0:18(6): error: float length(vec2) 0:18(6): error: float length(vec3) 0:18(6): error: float length(vec4) 0:18(6): error: double length(double) 0:18(6): error: double length(dvec2) 0:18(6): error: double length(dvec3) 0:18(6): error: double length(dvec4) 0:18(6): error: operands to relational operators must be scalar and numeric 0:18(6): error: if-statement condition must be scalar boolean Changing the shader to use: in vec3 icolor; in vec2 iuv; fixes the problem. This seems to be related to https://patchwork.freedesktop.org/patch/15298/, but the input variable check is too strict. It should work with an input block as well, which is for instance used by the G-Truc samples: https://github.com/g-truc/ogl-samples/blob/655559499c23b9566ac432cc2af33cde6646271c/data/gl-400/fbo-multisample-interpolate.frag Code in question works fine on AMD desktop drivers.