@Capehill
Now that I saw it: yes, definitely a Nova bug, no need to look at the source, thanks.

@Capehill
@kas1e
New ogles2 v3.0 wip version is on my FTP. I further improved the unused variable detector (whopping 185 lines now ). As a direct result it now also correctly detects the missing initialization of the int "temp" in this shader. Until now stuff like that could eventually slip through undetected because I didn't correctly handle certain OpDecorations (in this case RelaxedPrecision).

@Daniel
Yeah, works!

But now, when it not "forced" version, then in ShaderJoy we didn't have a warning window about non-init-vars, but only have them when enabled "verbose log" and it just hides in the deep of other output. + shader execution didn't stop. But that all to Capehill, of course :) Check ShaderJoy thread anyway.

@Capehill
@kas1e
Another ogles2 v3 wip update with even more improvements of the uninitialized variables detector is on my FTP. It now correctly detects even more stuff, e.g. in these shaders:

● KissingDonuts, "g" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Glowing Stone, "color"
● Aya Tunnel, "dO" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Glass looking modulo trick, "acc"
● Dancing circles, "f"

A stupid typo prevented the detection of some of those until now. Essentially this typo made the detector look for invalid jump target names in one situation, which in turn led to early quits. The second stupid typo eventually made the detector not start at the true entry point, also leading to early quits sometimes. This one was responsible for the other missed hits.
En passant the performance was increased significantly (although the detector's impact wasn't measurable before already ).

EDIT: didn't check if the followin weren't detected before, those were just coming around in the Mantis right now, so I quickly used those for verification.

● Valentiness, "z" (note: this is the only critical uninitialized variable here, despite what's being said here)
● Intricate circles, "col"
● Another Cloudy Tunnel, "vecOld"
● Solar distortion, "dpMin"

@Daniel
Yeah, detection is better for sure. From all Hans finds find out 2 ones which weren't detected:

http://www.amiga.org/developer/bugreports/view.php?id=592

http://www.amiga.org/developer/bugreports/view.php?id=596


One in MainImage() probabaly is out of detection as you explain before, but another one seems unitialized var in the image() function, so should be detected imho ?

Btw, offten we have in different function declared vars with the same name, and only one or some of them are really unitialized. Question is : is it of much hassle, in the error output with name of unitialized var print a number of string in the shader, or it all up to high level's code ?

@kas1e
Those are the two which I told you on FB cannot be detected "by design". The detector currently doesn't track such (in)outs, they are completely ignored. This won't change in the foreseeable future, most likely.

You mean line numbers? Those are gone in the SPIR-V, usually. However, I could add an aglSetParam-option to enable the emitting of OpLine instructions, which the detector could then pick up easily.
But IMHO that's not worth the bloat. Such shaders usually don't consist out of hundreds of lines. A search for the respective variable name will most often immediately and the rest of the time very quickly lead you to the critical location in the shader anyway.
But if you really want it real hard, then I'll add it
(but note that the line numbers won't necessarily be what you expect in case of ShaderJoy, because the listings get a trailing "invisible" static piece of code attached internally... So if I add support for this, then another optional int agl-parameter for a line-number report-offset would be mandatory, I guess).

@Daniel
No no, not of big deal. Just if it was something very simply like adding another byte to printf, but if not, no need to spend time on. Its good enough already :)

Does those shaders works if those unintialized vars are set manually ?
( I mean edit the shader)

Of course (that what we are talk about). But they tested with 1.74 betas of Nova, so not sure if they all will work after you fix vars with public 1.68.

OpenGL ES 2 version 3.0 for Warp3D Nova / AmigaOS4 has been finalized.
It's available on my FTP for testers and A-Eon devs, as usual, for a last check.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DEBUG_SHADER_LOG. If set to TRUE then the library asks Nova for extra shader compiler info. A detailed log will be returned even on successful shader compilation. If this flag is set to FALSE (default) then only the usual standard error log will be returned.

- extended the extensions string by GL_ARB_texture_non_power_of_two and GL_OES_texture_npot. The lib implicitely supported those since day one but not mentioning them explicitely in the ext-string could cause some progs to execute internal pot-scale workarounds or to fails needlessly.

- Fix: design flaw. Every shader had its own internal variable-cache. Which at first glance seems to be all good and which most often works. But actually it's wrong because that cache also handles the mapping of uniform locations. But those can vary for the very same shader if it's being used by multiple programs! So, this bug could cause all sorts of hard to track issues if the client used shared shader objects for multiple programs. Now the variable-caches have been moved into the program objects (simply spoken, in fact the shaders still have their own cache but the programs get their own autarkic set of dedicated variable-representations).

- while I was at it I trashed all the old program introspection code and rewrote it from scratch. As a result the lib now also supports uniform arrays. Sometimes trashing your old broken stuff is way better than trying to fix it - only to probably add more sideeffects. No, better accept your failure and start over

- extended the extensions string by GL_ARB_arrays_of_arrays. This is because the new introspection system didn't just add array support but multidimensional array support too.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS. If set to 1 or 2 (default 0) then the library will analyze the generated SPIR-V code and look for uninitialized shader variables. If set to 1 then it will only put a warning in the log and continue, if set to 2 then glCompileShader will return with an error if something suspicious is being detected.
Note that the scanner is considered "good enough for us", it's certainly not perfect (well, it cannot possibly be without simulating all possible inputs and fully emulating the shader, so... it's just a ~200 liner ;) ). While it does analyze all different code-paths (branches, conditional branches, function calls, loops) it will not detect stuff like a vector variable being only partially initialized (e.g. a vec4 whose .xyz are initialized but not its .a won't be detected) or structs that are only partially initialized (e.g. struct s {vec2 a; vec2;b} won't be reported if a is being set but b is not). Other than that it gives pretty good results with only a minimal, practically not measurable, performance impact on glCompileShader (depends on shader size / complexity / num variables, but even checking real big ones didn't hit performance measurably so far).
Thanks to kas1e for requesting!

- glslangvalidator_redux shell tool extended by an equivalent -varcheck option to enable scanning for uninitialized shader variables.

- Fix: standard violation. If you attached a texture to an FBO then a resize of said texture using glTexture2D should be enough to trigger a resize of the whole FBO. Before that fix this led to gfx coruption because Nova doesn't automatically handle that case neither. The necessary workaround until now was to unattach and reattach the texture to force ogles2 lib into updating the FBO. Now all you need is glTexture2D.
Thanks to Capehill for reporting!

- new aglCreateContext / aglSetParam parameters OGLES2_CCT_SPIRV_OPLINES (bool) and OGLES2_CCT_SPIRV_OPLINES_OFFSET (int) which extend the uninitialized-variables-detector by optionally telling you the source-code's line where the shite happened. For that it tells the integrated glslangvalidator to generate SPIR-V which contains OpLine opcodes, which in turn is now handled by the detector. OGLES2_CCT_SPIRV_OPLINES_OFFSET is useful to e.g. make the output 0 or 1 relative or to compensate for any eventual prefix (e.g. ShaderJoy adds a static prefix and should therefore adjust the offset).
Note that this feature is being disabled if you don't have installed the latest Nova 1.76+. Reason is that among some others it didn't correctly handle the OpLine opcode, which in turn resulted in the whole shader not being compiled at all.

- !don't forget to download the new include-folder too!

- version set to 3.0 (14.9.2020) (yep, it's that much of an improvement ;) )

Thanks to kas1e and Capehill for testing!

Cheers,
Daniel

@Daytona675x

Quote:
Is that Boolean uniforms support?
Or is that something completely different?

@Raziel
No, that's sth. completely different indeed.

Boolean uniforms are just uniform variables of type bool. Those are not supported by Nova yet, so when you try to use those inside a shader it won't compile.

This here is general support for arrays of uniform variables, like e.g. uniform float x[10];

Back in the early days of ogles2.lib I had blindly coded support for those, however Nova didn't support them at that time. As it turned out my code was partially buggy. The main problem was that the introspection system wasn't correct in terms of arrays, which prevented proper use of those.
This has now been fixed and improved.

@Daytona675x

A huge thanks for the recent release! My son can happily play Aquaria again on my X5000. So even though I also have Warp3D for Southern Islands, I think we'll be using your solution going forward.

One thing I have noticed is tha ScreenBlanker OpenGL modules no longer work as expected. Typically we end up with crashes, or occasionally they'll run for a bit with incorrect color data. Hopefully the following gets formatted correctly:


-- eliyahu

@eliyahu
Hi mate! That's a different construction site
The problem here is not ogles2 but MiniGL4GL4 which unfortunately is nothing but a very dirty hack with the primary goal to give Polaris users who are left without classic Warp3D support until now some last resort to play MiniGL games. If you have Southern Island and therefore native W3D classic support you should stick with the normal minigl libraries.

The thing with MGL4GL4ES is that it is pretty much just a GL4ES build with a MiniGL interface attached. Unfortunately GL4ES wasn't designed for being used inside a shared library which is why it's unstable as hell if being (ab)used this way. I'd have to make GL4ES fully reentrant first and replace all static and global stuff to make this a real alternative for old minigl. Until this is done (and I really can't say if or when I have time for this) it will have all sorts of issues, one of which is the screen-safer problem you're experiencing.

It's okay for many games which just open one window and without anything else running in parallel, but other than that...

@Daytona675x

Quote:
Whoops! Sorry for the confusion. Still, will probably stick with MGL4GL4ES when needed since it seems to allow Aquaria to run. I need to test some other games, too, with it.

Quote:
Understood. I appreciate the quick reply!

-- eliyahu

@Daniel
Maybe you have an idea what it can be, see for example that shader:

https://www.shadertoy.com/view/3lBfzz

It bring me such error:

Quote:

Or for example that multi-shader, and from it "BufferB" shader: https://www.shadertoy.com/view/XltSzj

That one bring such kind of error:

Quote:

Just want to be sure wtf :)

Hi,

On my machine (iMac) using safari, Blunderbuss shader also brings me error on lines 83 and 136, but works on Opera on the same machine.





Maybe it could help.

the second one works on both browsers.

Regards,
Petrol

@Petrol
Looks like different kind of errors meaning iMac/safari implementation of webgl worse than our ogles2.

@kas1e

You seem to have found a Shaderjoy issue. It seems that iFrame should be int and not float. Try changing line 150:

if (iFrame > 5.0)

Does it help?

Same thing for BufferB/line 103:

if (iFrame <= 4.0 ...

EDIT: https://www.shadertoy.com/howto suggests "float iFrame". I wonder now which one it should be.

@Capehill
@kas1e
It should be "int iFrame". At least that's what the web client uses. Go to https://www.shadertoy.com/view/3lBfzz and expand the "Shader Inputs" panel on top of the GLSL source code.