command line flag to disable autorun

[claudeha]

Is your feature request related to a problem? Please describe. Working on a shader which somehow takes way too long to compile. Somehow I got FragM into a state where that beast autoloaded, and autobuilt on load, so my session was basically wedged. FragM didn't crash, I killed it because it takes too long, so maybe that's why the automatic de-autorun didn't kick in?

Describe the solution you'd like --no-autorun command line flag that is simple to discover via --help

Describe alternatives you've considered Finding the preferences in ~/.config/Syntopia_Software/Fragmentarium.conf and setting autorun=false worked but isn't very friendly.

Additional context OS: Debian Bullseye/Sid testing/unstable

[3Dickulus]

yep, good idea, cmdline option for autorun, just a few lines in main.cpp should do it... should probably have everything in Edit->Preferences available as cmdline options and vice versa... language and gui style should be in Edit->Preferences

I would like to dig into the "state" a little bit, after setting autorun=false how long does the frag take to build after loading source? if it's extremely long the first build but a lot faster on subsequent builds I think that may indicate reading or writing uninitialized stuff. Other things might be... too many if-then-else clauses, lots of boolean ops, overly convoluted execution flow that gets figured out the first time and only needs to be recalculated when that part of the frag is affected by a change (thinking compiled binary delta from cache) ?

I have run into this with some of the Benesi frags and my own that just went too far with what seemed a good thing, taking very long time to compile but only sometimes, seemed very inconsistent, I never nailed down why it was so, just accepted the idea that GPU has limits on binary size and compiler doesn't like pushing the limit with monstrous fragment source designed to run as a single shader program.

edit: if the de-autorun didn't kick in it never finished the compile/fail cycle.

[claudeha]

My frag was using the regular DE-Raytracer, and my default preset enabled (locked) hard shadows, so it built twice (at least). Took about 40mins total I think. Sometimes tiny changes would result in much shorter or longer compilation times, seemingly random. Compilers are weird I guess. At least the shader compiler seems to cache things somewhere, so rebuilding if nothing has changed at all is almost instant.

[3Dickulus]

look at Edit->Preferences->Locked uniforms use #define or const

checked = use #define unchecked = use const

see if that helps... googling the issue shows that others have the same problem, when using large arrays in compute shaders, but I haven't found anything definitive on exactly what causes this or if there is a solution... shaders compiling with no errors taking upwards of 40 minutes is excessive. There has to be a way to improve that...

...came up with this discussion re:hsl-to-glsl... https://community.arm.com/developer/tools-software/graphics/f/discussions/3545/glcompileshader-taking-a-long-time I found it very informative and will try to keep things in mind when tinkering with GLSL.

[3Dickulus]

so it built twice (at least).

it will require building twice if initial instance of hard shadows is not locked and then the Default preset applies Locked to hard shadows or the value changed... this is expected behaviour.

have you tested with offline GLSL compiler ? the source from Render->Output Preprocessed Script should be compilable.

[claudeha]

Some changes to my frags (and maybe a driver upgrade, not sure) and it takes 80 seconds, which is much more acceptable (still not great). But that's not a fragm issue, using a standalone program the same happens, and using an offline GLSL compiler (near instant) the time leak was pushed into glSpecializeShader().

Thanks for the command line flag, tested and works!

[3Dickulus]

80 seconds for a heavy frag seems better cheers!