[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

Ilia Mirkin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Ilia Mirkin  ---
(In reply to Younghun Jang from comment #10)
> No one seems to care about this easily avoidable bug. Alright. Just waiting
> for someone to rediscover this and make a duplicate.

No, I care. And I pushed out a fix... just forgot to update the tracker.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=0332c7484b712e56ce1a6648c5fa04c90e286c37

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #10 from Younghun Jang  ---
No one seems to care about this easily avoidable bug. Alright. Just waiting for
someone to rediscover this and make a duplicate.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #9 from Younghun Jang  ---
(In reply to Ilia Mirkin from comment #8)
> This patch fixes the sample case for me:
> 
> https://patchwork.freedesktop.org/patch/191532/

I concur. The patch fixes the bug.

And I believe this was a typo:

   uint16_t swizzle_x = GET_SWZ(op[2]->swizzle, 0);
   uint16_t swizzle_x = GET_SWZ(op[2].swizzle, 0);

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #8 from Ilia Mirkin  ---
This patch fixes the sample case for me:

https://patchwork.freedesktop.org/patch/191532/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #7 from Tapani Pälli  ---
(In reply to Younghun Jang from comment #6)
> I don't think this would help because as I mentioned in the original
> comment, I could find the bug pretty much everywhere. VBox, my PC(AMD), GTX
> 960(nouveau) with or without `LIBGL_ALWAYS_SOFTWARE=1`. I'm more than
> confident that any Linux browser running Mesa driver would display the red
> canvas.
> 
> 
> 
>   $ glxinfo | grep "OpenGL renderer string"
>   OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (AMD POLARIS10 /
> DRM 3.18.0 / 4.13.13-300.fc27.x86_64, LLVM 4.0.1)
>   $ LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep "OpenGL renderer string"
>   OpenGL renderer string: llvmpipe (LLVM 4.0, 256 bits)

It does usually help in figuring out where the bug is. As example I cannot
reproduce this bug on i965 driver (on Kabylake) so it indicates that this bug
might be gallium specific.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

Younghun Jang  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #6 from Younghun Jang  ---
I don't think this would help because as I mentioned in the original comment, I
could find the bug pretty much everywhere. VBox, my PC(AMD), GTX 960(nouveau)
with or without `LIBGL_ALWAYS_SOFTWARE=1`. I'm more than confident that any
Linux browser running Mesa driver would display the red canvas.



  $ glxinfo | grep "OpenGL renderer string"
  OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (AMD POLARIS10 / DRM
3.18.0 / 4.13.13-300.fc27.x86_64, LLVM 4.0.1)
  $ LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep "OpenGL renderer string"
  OpenGL renderer string: llvmpipe (LLVM 4.0, 256 bits)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #5 from Ian Romanick  ---
(In reply to Ian Romanick from comment #4)
> (In reply to Ilia Mirkin from comment #3)
> 
> >(expression vec3 * (record_ref (var_ref u_s) color)
> >   (array_ref (record_ref (var_ref u_s) arr) (constant 
> > int (0)))
> >)
> 
> This should be fine.  For a bunch of things we allow mixing scalars and
> either vectors or matrices.  The shader_runner test passes on i965, so maybe
> the problem is in st_glsl_to_tgsi?

This is a thing that SPIR-V does not allow (except for multiply which has
special vector-times-scalar opcodes).  For part of the SPIR-V work I wrote a
pass that adds the missing swizzles.  It may be easiest to use that to massage
the GLSL IR before TGSI conversion.

We don't want to use this in general because may of the optimization passes
cannot "see through" a swizzle.  Algebraic optimizations, for example, can't
see that (+ (a) (swizzle  (* (b) (c is a MAD.  Also related to the
SPIR-V work, this is a topic I've been thinking about lately...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Ian Romanick  ---
(In reply to Ilia Mirkin from comment #3)

>(expression vec3 * (record_ref (var_ref u_s) color)
>   (array_ref (record_ref (var_ref u_s) arr) (constant int 
> (0)))
>)

This should be fine.  For a bunch of things we allow mixing scalars and either
vectors or matrices.  The shader_runner test passes on i965, so maybe the
problem is in st_glsl_to_tgsi?

(In reply to Younghun Jang from comment #0)
> I wanted to know if this bug is hardware related.

What hardware were you running on?  The output of 'glxinfo | grep "OpenGL
renderer string"' would help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #3 from Ilia Mirkin  ---
The GLSL IR seems questionable too...

: GLSL IR for linked fragment program 3:
(
(declare (location=2 shader_out ) vec4 gl_FragColor)
(declare (temporary ) vec4 gl_FragColor)
(declare (location=0 uniform ) Set@0x22dfe20 u_s)
( function main
  (signature void
(parameters
)
(
  (declare (temporary ) vec4 vec_ctor)
  (assign  (w) (var_ref vec_ctor)  (constant float (1.00)) ) 
  (assign  (xyz) (var_ref vec_ctor)  (expression vec3 * (record_ref
(var_ref u_s)  color) (array_ref (record_ref (var_ref u_s)  arr) (constant int
(0)) ) ) ) 
  (assign  (xyzw) (var_ref gl_FragColor)  (var_ref vec_ctor) ) 
  (assign  (xyzw) (var_ref gl_FragColor@3)  (var_ref gl_FragColor) ) 
))

)

)

It multiplies directly by the array_ref -- there should be a swizzle or other
vec3 conversion on there, no? Or perhaps you're allowed to have vecN * float
directly in the IR. Not sure.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #2 from Ilia Mirkin  ---
Created attachment 135757
  --> https://bugs.freedesktop.org/attachment.cgi?id=135757=edit
shader_test that repros the issue

In the TGSI this comes out as

FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL OUT[0], COLOR
DCL CONST[0][0..3]
DCL TEMP[0..1], LOCAL
IMM[0] FLT32 {1., 0., 0., 0.}
  0: MOV TEMP[0].w, IMM[0].
  1: MUL TEMP[0].xyz, CONST[0][0].xyzz, CONST[0][1]
  2: MOV TEMP[1], TEMP[0]
  3: MOV OUT[0], TEMP[1]
  4: END

Which is clearly bogus. That needs to be CONST[0][1].xxx

Haven't looked further than that. This sounds familiar though for some reason.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

--- Comment #1 from Younghun Jang  ---
(correction)
I made a wrong assumption about Chrome's SW renderer. Running Chrome with
`LIBGL_ALWAYS_SOFTWARE=1` does not make Chrome default to its own SW renderer.
This only happens with VBox GPU.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103955

Bug ID: 103955
   Summary: Using array in structure results in wrong GLSL
compilation output
   Product: Mesa
   Version: 17.3
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: miea...@gmail.com
QA Contact: intel-3d-b...@lists.freedesktop.org

Created attachment 135756
  --> https://bugs.freedesktop.org/attachment.cgi?id=135756=edit
Windows port of the test program

Declaring a uniform structure, whose one member is an array of float, results
in wrong shader code. Consider the following fragment shader:


struct Set {
vec3 color;
float arr[3];
};

uniform Set u_s;


void main () {
gl_FragColor = vec4(u_s.color * u_s.arr[0], 1.0);
// gl_FragColor = vec4(u_s.color * vec3(1.0, 0.0, 0.0), 1.0);
}


This fragment shader should output FragColor of white(that is `vec4(1.0, 1.0,
1.0, 1.0)`) if the value of `u_s.arr[0]` is 1.0. However, the shader compiled
by Mesa driver produces `vec4(1.0, 0.0, 0.0, ?)`, which is red. The alpha
component is disregarded since GL_BLEND is disabled in the test application.


I wanted to know if this bug is hardware related. The attachment is the
makeshift test program I wrote with an existing example(in the courtesy of
opengl-tutorial.org) to demonstrate the bug. I found this bug when I was
developing a WebGL web app, so I wrote the test web page as well.

   https://ashegoulding.github.io/attmnts/array_in_struct_uniform.html
   https://ashegoulding.github.io/attmnts/array_in_struct_uniform.zip

I also ported the test program to Windows. The bug is not reproducible on
Windows in whichever way.

On Linux running the Mesa driver, Firefox, Google Chrome displays a red
framebuffer. The bug is still seen running the browsers/test app with
`LIBGL_ALWAYS_SOFTWARE=1`, except for Chrome[1]

I'd also like to mention that I ran the test program and the web page with
`MESA_GLSL=dump`, `MESA_GLSL=uniform` to see if there's any form of "shader
source translation" like ANGLE does on Windows. The dump of the source code and
uniform upload were identical.

The bug is still there on 17.3.0-rc5 and 17.2.6.



[1]
Chrome browser defaults to its own software renderer when a slower renderer(SW
or VBox GPU) is detected. The canvas is white with that renderer.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev