@kas1e
Fantastic, thanks This will surely lead to further improvement!

EDIT: improvements added Now all the ones you sent me are detected correctly too.
Had to add support for OpAccessChain and variants to catch component-wise assignments, add support for OpLoopMerge to be able to add some special treatment for stuff like for-loops, and added a hack to detect inout-variables (unfortunately SPIR-V doesn't decorate those).
Code grew from 150 to 180 lines

Quote:
Phew, honestly: as soon as a bug is so severe that the GPUs internal CU workings are visually revealing and as soon as the shader gets more complex, I wouldn't waste my time on it considering the known register handler's state.

@kas1e
Quote:
No, looks okay to me.

@Capehill
Quote:
Good idea! I just started, come join

@NikJ
Welcome and cheers! Well chosen setups and forum

@kas1e
I have to repeat it (edit: oops, did you edit your text?):
Those shaders are not standard compliant! Why waste time and resources cleaning up after those?
And where would it end? Take a look at that mod(x,0) thing, same:
this shader relies on non-standard compliant drivers! Some Windows drivers (e.g. my NVidia here) silently help it by not returning NaN or whatever. Other drivers (e.g. Capehill's Radeon) dont. So this shader doesn't even just not work on our side.
Do you also want this behaviour to be changed to match my NVidias? Why? Really, it doesn't make sense. The standard and its definitions are there for a reason, one reason being that the answer to your request can be a clear "No"

Quote:
Once the uninit var detector works reliable, I could add extra OpStore init commands with ease. But with "costly" I mean shader execution time. If the detector is not 100% perfect (and it probably won't) then you eventually add needless initializations for other vars. IMO it's just a waste to do any such action just to fix broken shaders.

Quote:
I doubt that. Please do as I asked you, send them over. I know for sure that the uninit detector doesn't work reliable enough yet and it will produce wrong positives as well as let stuff through undetected.

@kas1e

No, you are wrong.
First of all you unrolled it wrong. You replaced i by 1, 2 and 3 but it should be replaced by 0, 1, 2.
Then lets take a look at the math if we put in a 0 for i:

1.0 / abs(mod(st.y + st.x, 0.1 * 0) * 1000.) * 1.;
= 1.0 / abs(mod(st.y + st.x, 0.0) * 1000.) * 1.;

So we end up with a mod(x,0). This is undefined math!
mod is evaluated like this:

mod(x,y) = x-y * floor(x/y).

And in our case here y is 0, so we got a nice division by zero
So with your false unrolling you accidentially fixed the broken shader

@Capehill
This of course also explains why it fails on Windows for you

@jabirulo
However, I fail to explain why your own unrolled do while version works. Random driver magic or luck, I guess

Anyway, another shader that turns out to be crap, Nova is all good here and a black screen is a pretty valid result for such a thingy...
All this in turn means that if you correct the loop to run like

for (float i = 1.; i < 4.; i++) {

which is what you falsely unrolled it to , then it works because the hidden division by zero is gone.

HOWEVER:
When I unroll the corrected loop this way

float i=1.0
r += 1.0 / abs(mod(st.y + st.x, 0.1 * i) * 1000.) * 1.;
r += 1.0 / abs(mod(st.y - st.x, 0.5 * i) * 10.) * 1.;
i++;
r += 1.0 / abs(mod(st.y + st.x, 0.1 * i) * 1000.) * 1.;
r += 1.0 / abs(mod(st.y - st.x, 0.5 * i) * 10.) * 1.;
i++;
r += 1.0 / abs(mod(st.y + st.x, 0.1 * i) * 1000.) * 1.;
r += 1.0 / abs(mod(st.y - st.x, 0.5 * i) * 10.) * 1.;


Then I get an ugly Nova compilation error
Need 263 VGPRS, which exceeds the maximum of 256.
So there is a good old Nova register bug after all

@Capehill
Yes, you are correct. In the context of Shadertoy iOS this shader is broken and will only work with drivers which are silently initializing the rgb components too.
But I suggest not to complicate the matter by referencing other systems / other applications:
in our case in your ShaderJoy implementation the variable is being set to 0,0,0,1, so in our context the shader is valid and Nova produces garbage.

EDIT: I stand corrected! What Nova does here is not wrong. I overlooked that your shader's variable is an out and not an inout. Therefore the initialization in main is not being of any use. So we have no Nova bug in this case here! But the shader is broken everywhere, only that other drivers silently fix it (which is sth. Nova should not do IMHO, don't encourage people to write wrong code)

@kas1e
Ouch! You know what's happening here?
Nova ignores the vec4(0,0,0,1) assignment in the shader's main (what you pasted here is just the mainImage func). The variable o is initialized before this function call. However, Nova apparently forgot about that. If you add the redundant and unnecessary line o=vec4(0.0); at the function's start, then it will work with Nova.
Obviously Hans messes up function parameters or better the respective registers. That's absolute core functionality which is broken.

EDIT: That was a wrong anaylsis from my part, see here

@kas1e
smoothstep is a basic GLSL function.

Quote:
Who knows. As always: with this broken register allocator everything is possible.
I suggest to simply report it as another seperate bug, just like you did before, symptoms plus shader code.

@kas1e
Quote:
We'll see how many are uninitialized for real As I said it's likely that this beta detector still produces false positives, after all you're the first one who tests it for real Just send over the respective shaders in question.
But yes, of course ShaderJoy should use 1 for this mode, not 2.

Quote:
Don't waste your time with this until I verified that the detector didn't return a false positive! Which is actually more likely than lots of uninitialized vars Just send em over and let me take a look.

@Capehill
Great, thanks, looking forward to 1.9! You may want to download another fresh lib version. More optimizations for the SPIRV uninit var detector, resulting in even higher performance and less C++ code (now 159 tiny lines incl. class defs, no STL, no clib, just one dyn memory allocation (plus those for the warning string, if there's any)). I'm really curious if you can even measure any glCompile difference between enabled / disable var checker.

@Capehill
Great, thanks
IIRC you have beta access to my FTP (if not, drop me a PM). If you want you can already download the fresh includes and the beta ogles2 3.0 lib from there and already implement support for two new aglCreateContext / aglSetParam options:

- 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.

- OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS: If set to 1 or 2 (default 0) then ogles2.lib 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: OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS is beta, I wrote it yesterday. It's certainly not perfect (altogether less than 150 small lines of code, incl. the SPIRV parser, no kidding ) but seems to do a decent job so far - obviously not tested toooo much though. So if you encounter a shader which gives wrong results, throw it into a mail or on my FTP please.
You'll also find an updated glslangvalidator_redux on my FTP which has that feature.

@Capehill
Here's one entry of my wishlist if you don't mind
Apparently Shaderjoy's verbose logging only spits out the shader-log if an error occured. I think it would be better if you'd always print it in "verbose" mode (maybe check GL_INFO_LOG_LENGTH).

@kas1e
Yes, that's what I meant.

@Capehill
Quote:
Offline sucks

Quote:
AFAIK they don't support that feature.

Quote:
Hm, have to correct myself: actually a good-enough-for-our-purpose analysis should be pretty easy to do, almost trivial and without any severe impact (at least that impact should be small enough to not increase Nova's rather long shader compilation time by any significant measurable additional amount). With good-enough-for-us I mean that stuff like this missing col initialization in those previous shaders would be detected.
EDIT: added this feature to ogles2.lib. SPIRV is such a clean and extremely simple and easy to handle format, it was almost a no-brainer to do.

@kas1e
Quote:
It's nice to have, not vital of course. But if it's a flag for e.g. CompileShader I could make it switchable via an aglFunction. Would be a nice feature for ShaderJoy. It would also help to quickly check whether a shader with buggy output produces its pixel garbage because of an uninitialized variable or not.

Quote:
No. It has no negative side-effects (other than a certain performance loss, if that's measurable is another question).

Quote:
No, because you essentially change a purely undefined state to a well defined state. And that defined state is a subset of all the possible random states it could have had before

@Capehill
Quote:
This behaviour is not just allowed but also not considered to be worth a warning. Nova is not buggy here, so I have to second Hans that there is no action to be taken. Yes, it would be nice but on the other hand it also will result in unnecessary warnings. And such a analysis is not trivial and not for free. After all there are very valid reasons - unlike in those broken shaders - not to initialize a variable right upon declaration.

@kas1e
Quote:
No, it's just that some (maybe even most, or even all, doesn't matter) Windows OpenGL drivers apparently set uninitialized variables to 0 even though the standard explicitly does not require it. Or to put it simple: the respective shaders are buggy, not Nova. Those shaders rely on something they simply must not rely on.
However, since real-life shaders often seem to falsely rely on this behaviour, maybe a Nova feature request for an init-vars-to-zero-toggle (default off like now) is a good compromise.

Quote:
Novas register handling is still broken and therefore all sorts of fun can happen. You or I cannot say for sure which exact issue it is. We cannot even say for sure if it has to do with the register allocator, it's likely but we cannot be sure. Maybe it's a different bug with familiar looking symptoms. The thing is: with those Shaderjoy shaders it is natural that whatever is the problem results in pixels being falsely colored, simply because Shadertoy is all about pixel colors and nothing else ;)
Anyway, either create one bug-report named "All sorts of pixel garbage" and then extend it with more and more links to shadertoy-shaders - or create one report for each buggy shader, maybe with a not that you somewhat guess that it may be related to bug or report xyz. But don't try to be smart and to categorize further After all you are a reporter. It's Hans job to fix that stuff and it's also his job to analyse and eventually merge or split your bug reports.

Quote:
IMHO a rewrite of the register allocator is due. From what I see things get fixed in lib release A only to reappear in a slightly different form or the fixes cause other problems as sideeffects. And then there is also the missing register spilling etc.
For the upcoming ogles2 lib version I threw away and rewrote the whole program introspection system Yes, certainly no fun but sometimes you have to admit to yourself that what you did before was no good and that a rewrite with a fresh head is the far better choice, instead of putting even more patchs on that old rag rug.
In my experience this always pays off.

@kas1e
I guess it's not a general "and" doesn't work but simply depends on situation, which register used when etc. After all an && in this case here will certainly result in two conditional branches, just like at least the 1st working variant. It's worthless to speculate more, if register allocation is messed up everything is possible.

@kas1e
to me this looks like similar issues, I bet it's some register mess up in each case.
Btw.: I played a bit with the previous one.

@kas1e
That's some new severe bug introduced in Warp3D Nova 1.70. Check it out, with 1.68 it still renders fine.
Apparently the reason now is an "if" not working correctly anymore. In case of this shader it's this one:



I checked d, b and p.y, they seem to be valid.

Quote:
I'd not be so sure about that. Looking at all those recent bugs the main broken component of Nova seems to be the register allocator which can result in all kinds of funny stuff. I mean, maybe the above "if" is simply comparing the wrong register.

@Capehill
Quote:
LOL, indeed, thanks

Quote:
Well, not at all. The thing is that I didn't really know what to put there because Nova lacks commands etc. which are mandatory, that's why I put this 0.9 there, to refect this. I will re-check current Nova state and reconsider this string's content for the upcoming ogles2 update.

@Breed
thanks & cheers, mate

@ddni
I watched on 2nd screen

@all
New Atomic Bomberman version 2.10 (network protocol version 13) is now available (via auto-updater or get it from my homepage )
This update mostly contains the first pile of stuff which we noticed yesterday evening when doing an intense atomic session

- new gameplay option: no sleepy players. If a player has been inactive for 15 seconds, it will auto-drop a bomb... Highly recommended, especially for network games!

- networking: the master can now manually increase / decrease the waiting-for-clients-countdown by tapping left / right. Yesterday we had a situation where I missed exactly that feature: ErnstEiswürfel was about to join but only 15 seconds remained, so he just missed it and everybody had to quit and rejoin.

- Fix (was uncritical, but...): "toilet mode" isn't a configurable input mapping anymore Forgot to set the non-editable flag for this fixed mapping, which is why the auto-configuration system of my framework made it configurable in the controls menu.

- (maybe) fix, networking: ddni and ErnstEiswürfel reported a weird issue that to me looks as if their network connection was sometimes so instable that some crucial state change packages would pile up - and then suddenly be executed one after the other without any delay. That resulted in situations where it looked as if the scenery was changing all of a sudden - although other players experienced it as what it was: matchend, result-screen, next round. But for them it was more like matchend (or shortly before matchend) -> next round, the result-screen would essentially be skipped or visible as a black screen for one frame. Well, that's my guess because I don't have another explanation So to work around that I extended the network protocol by dedicated sync-commands for those screen-changes. Crossing fingers, untested
Thanks to ddni for recording a video of that phenomenon!

- (maybe) fix, networking: for some Amiga players at least a hard master drop would result in their client to appear frozen. It didn't crash though, it was simply waiting for a TCP timeout on the socket which was closed by the master. Apparently it's no good idea to rely on the TCPIP stack's error handling here. Therefore the master now sends an explicit "server-death"-message to all clients before shutting down. Only tested on Windows so far.
Thanks to ErnstEiswürfel and ddni for reporting!

- made 4711 the default network port for no particular reason other than that I chose it for testing Yes, I know that it's used by other services (just like probably every TCP port) and I don't care at all.

- Windows, auto-updater: the self-deletion of the update installer eventually triggered some stupid antivirus software :P Disabled the self-deletion step, hope that does the trick.
Thanks to Valentin for reporting and analyzing!

- Windows, auto-updater: now 64 bit executable.

Cheers to Krusher, amosian, ErnstEiswürfel, ddni and aPEX (who was a bit too late, but there was a will!), kill you soon!

Tchatching,
Daytona675x / Inqui / Daniel