jamienicol / glsl-optimizer Goto Github PK

I added https://github.com/aras-p/glsl-optimizer to our WebGL artwork pipeline recently, well aware that it's unmaintained.
I assumed that most of the features we'd depend on would be stable, and that the optimizer would catch trivial cases.
However, we have had at least 2 bugs introduced by glsl-opt + one crash; often times the optimizer doesn't do trivial optimizations or dead-code-elimination.

This seems to be one of the most heavily modified and active glsl-optimizer forks, so I gave it a shot.

Your fork seems to avoid at least some of these issues. We also get new errors and warnings which went unnoticed (even with shaders in production).

I'd like to switch our production artwork pipeline to your fork, but I'd like to see these questions answered in the README:

• Where is it used? (or where is https://github.com/jamienicol/glslopt-rs used?)
• Is it considered stable?
• Is it actively maintained (by single user, group or an organization?)
• What are planned changes / goals? (just mesa updates?)
• Will it remain usable as standalone tool or is focus on turning it into a lib? (we use glslopt directly, specifically for GLSL ES 1.00)
• Will there be tagged releases? (we are currently using the same version as the glslopt-rs submodule for published releases)
• Which other forks (or even separate optimizers) would you recommend for other use-cases?

If you want to attract more users I'd suggest to remove the fork-status of this project (because forks won't show up in the GitHub search).
You should also have your fork integrated in https://github.com/tgjones/shader-playground so people can experiment with it more easily.

Copied from aras-p#150

We are exploring the use of storage buffers in WebRender, and glsl optimizing stage
unfortunately doesn't recognize them. Example syntax we use:

layout(std140, binding = 0) buffer bInstances {
    ivec4 bInstanceData[];
};

This is code in GLES 3.1, and under "GL_ARB_shader_storage_buffer_object" extension in GL.

Thanks for this library :)
I'm trying to use it to optimize GLSL that resulted from Rust being compiled to SPIR-V and then to GLSL.
But it fails in this line:

GLSL optimization log:
0:63(40): warning: `_77' used uninitialized
0:64(40): warning: `_77' used uninitialized
0:65(40): warning: `_77' used uninitialized
0:70(20): warning: `_71' used uninitialized
0:74(20): warning: `_71' used uninitialized
0:78(20): warning: `_72' used uninitialized
0:89(69): warning: `_100' used uninitialized
0:90(20): warning: `_72' used uninitialized
0:96(20): warning: `_72' used uninitialized
0:107(80): warning: `_101' used uninitialized
0:108(20): warning: `_72' used uninitialized
0:114(20): warning: `_72' used uninitialized
0:120(20): warning: `_72' used uninitialized
0:126(20): warning: `_73' used uninitialized
0:146(20): warning: `_71' used uninitialized

rustoy: glsl-optimizer/src/util/ralloc.c:95: get_header: Assertion `info->canary == CANARY' failed.
Aborted (core dumped)

This is the GLSL code:
https://dpaste.com/5XGJTHTV8
(The same happens when I use #version 120 as compilation target.)

Any idea how to make it work? :)

Btw, I'm calling it through the glslopt crate like this:

pub fn optimize_glsl(glsl: String) -> Result<String> {
    let res = Context::new(Target::OpenGles30).optimize(ShaderType::Fragment, glsl);
    println!("GLSL optimization log:\n{}", res.get_log());
    ensure!(res.get_status(), "GLSL optimization failed. bad status");
    let glsl = res.get_output()?.to_string();
    Ok(glsl)
}

This is from mozilla bugzilla issue
https://bugzilla.mozilla.org/show_bug.cgi?id=1633092
TB build failure: GLSL optimizer output causes a compiler error (GCC-9) error: comparison of integer expressions of different signedness: ‘long int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compar

I am attaching the patch to fix the warning (= error under my local setting.) as text file.
(Well attachment is only allowed in certain types (detected by the suffices, I think, and .diff is not one of them.)

One is actually an unused variable in
src/compiler/glsl/ir_print_glsl_visitor.cpp: const bool is_lod
mozilla-bugzilla-1633092.txt

TIA

This appears to be similar to the "multithreading causes glslopt to crash" issue from some years ago, but now arises (only) when building Firefox with LTO enabled.

The crash should be easy to reproduce: Just try building the firefox_116.0-2 package on Debian unstable on amd64, with DEB_BUILD_MAINT_OPTIONS=optimize=+lto set in the environment. The build should fail along these lines:

   Compiling webrender v0.62.0 (/tmp/firefox-116.0/gfx/wr/webrender)
     Running `/tmp/firefox-116.0/build-browser/release/build/webrender-503c370365efbdbf/build-script-build`
[webrender 0.62.0] cargo:rerun-if-changed=res
[webrender 0.62.0] cargo:rerun-if-changed=res/shared_other.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/ps_split_composite.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/base.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/yuv.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/ellipse.glsl
[...]
[webrender 0.62.0] cargo:rerun-if-changed=res/cs_border_segment.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/brush_solid.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/brush_yuv_image.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/cs_conic_gradient.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/cs_clip_image.glsl
[webrender 0.62.0] Optimizing shader ShaderOptimizationInput { shader_name: "cs_svg_filter", config: "", gl_version: Gl }
error: failed to run custom build command for `webrender v0.62.0 (/tmp/firefox-116.0/gfx/wr/webrender)`

Caused by:
  process didn't exit successfully: `/tmp/firefox-116.0/build-browser/release/build/webrender-503c370365efbdbf/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
  --- stdout
  cargo:rerun-if-changed=res
  cargo:rerun-if-changed=res/shared_other.glsl
  cargo:rerun-if-changed=res/ps_split_composite.glsl
  cargo:rerun-if-changed=res/base.glsl
  cargo:rerun-if-changed=res/yuv.glsl
  cargo:rerun-if-changed=res/ellipse.glsl
[...]
  cargo:rerun-if-changed=res/cs_border_segment.glsl
  cargo:rerun-if-changed=res/brush_solid.glsl
  cargo:rerun-if-changed=res/brush_yuv_image.glsl
  cargo:rerun-if-changed=res/cs_conic_gradient.glsl
  cargo:rerun-if-changed=res/cs_clip_image.glsl
  Optimizing shader ShaderOptimizationInput { shader_name: "cs_svg_filter", config: "", gl_version: Gl }
make[3]: *** [/tmp/firefox-116.0/config/makefiles/rust.mk:436: force-cargo-library-build] Error 101
make[3]: Leaving directory '/tmp/firefox-116.0/build-browser/toolkit/library/rust'
make[2]: *** [/tmp/firefox-116.0/config/recurse.mk:72: toolkit/library/rust/target] Error 2
make[2]: Leaving directory '/tmp/firefox-116.0/build-browser'
make[1]: *** [/tmp/firefox-116.0/config/recurse.mk:34: compile] Error 2
make[1]: Leaving directory '/tmp/firefox-116.0/build-browser'
make: *** [/tmp/firefox-116.0/config/rules.mk:361: default] Error 2

The crash is firmly predicated on LTO being enabled. With LTO => crash, without LTO => success. My current workaround is to hide the LTO flags from the Rust part of the build---I don't know how to hide them from just webrender/glslopt---but that is obviously not ideal.