This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[BUG] Adding 0.0 to an expression causes significant visual difference

The following issue is also logged here, which links to the relevant files

Platform details are at the end.

This fragment shader:

https://github.com/mc-imperial/shader-compiler-bugs/raw/master/ARM-Mali-T628-Chromebook-WebGL/wrong_images/small-v100-we…

causes this image to be rendered:

original.png

In contrast, this shader:

https://raw.githubusercontent.com/mc-imperial/shader-compiler-bugs/master/ARM-Mali-T628-Chromebook-WebGL/wrong_images/sm…

causes the following similar but visually distinct image to be rendered:

variant.png

The shaders are identical, except in the second shader, this line from the first shader:

    vec3 b = fract(sin(co.x * 0.3e-3 + co.y) * vec3(8.1e5, 1.0e5, 0.1e5)); 

has been replaced by:

    vec3 b = fract(sin(co.x * 0.3e-3 + co.y) * (vec3(8.1e5, 1.0e5, 0.1e5) + vec3(injectionSwitch.x, 0.0, 0.0))); 

At runtime, we set injectionSwitch to (0.0, 1.0), so adding vec3(injectionSwitch.x, 0.0, 0.0) should be like adding a vector of zeroes; i.e., it should have no effect. Yet making this change causes a visible difference in the image that is rendered.

Platform details:

- Samsung Chromebook

- Chrome OS

     * Version: 54.0.2840.101

     * Platform: 8743.85.0 (Official Build) stable-channel peach_pit

     * Firmware: Google_Peach_Pit.4482.95.0

- GPU: ARM Mali-T628

Version and renderer info obtained via WebGL API:

"GL_VERSION": "WebGL 1.0 (OpenGL ES 2.0 Chromium)",
"GL_SHADING_LANGUAGE_VERSION": "WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)",
"GL_VENDOR": "WebKit",
"GL_RENDERER": "WebKit WebGL",
"UNMASKED_VENDOR_WEBGL": "ARM",
"UNMASKED_RENDERER_WEBGL": "Mali-T628"
Parents
  • Hi Ally,

    We've not managed to reproduce this with the latest driver for the Midgard GPU family (Mali-T* GPUs), so it's possibly already fixed in devices running a newer release drivers.

    We're trying to work out exactly when this was fixed to give you a more precise driver revision to aim for, and will provide feedback to the device manufacturer.

    Kind regards,
    Pete

Reply
  • Hi Ally,

    We've not managed to reproduce this with the latest driver for the Midgard GPU family (Mali-T* GPUs), so it's possibly already fixed in devices running a newer release drivers.

    We're trying to work out exactly when this was fixed to give you a more precise driver revision to aim for, and will provide feedback to the device manufacturer.

    Kind regards,
    Pete

Children
No data