Warp3DNova shader bugs thread

@kas1e
Quote:
No, looks okay to me.

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

@Daniel
About unitialized vars: On ftp, reports_here/uninit_vars_tests.lha. Just packed 25 random ones (i think only few of them will be falsely positive, while in most it correctly warn).

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

@All
So far all rendering bugs for all shaders I wrote about there were fixed in new betas of Nova, as well as many others. There still some other left, but Hans deals with them step by step.

Currently, I report about 50 rendering bugs, 30 of which were fixed and 20 left. There are also about 10 crashes to deal with, and then that SGPRs/VGPRs limitation. After that, only some missing instructions left, but in general, almost 90% of all shaders from shadertoy will works if there will be no rendering issues and no SGPRs/VGPRs limits.

@kas1e

That's a great progressing ... but when i come on that site i read there are more than 40.000 shaders examples! .. even assuming that fixing one in Nova could fix tons of them at the same time, i wonder how we can test all of them or even a part of

@kas1e

I have seen some of the reports. Great testing and great progress.

I cannot comment closed reports so regarding #526 (Jupiter II), the random placement of stars is also broken on my Win7/Radeon.

@samo79
Quote:

It's enough to test just a few hundreds of random ones, to find out common errors and issues. But currently, I test probably around 2000 and have pretty good understanding of what kind of issues are left in general. After rendering issues the real remain issue is SGPRs/VGPRs limit, it makes too many heavy and very-good-looking shaders to fail. There are also some non-implemented instructions left too (like OpImageSampleExplicitLod and OpFwidth which used from time to time), but for real if all rendering issues I report fixed and SGPRs/VGPRs limitation removed, then we can say "all fine", even if some stuff will still fail.

Also, in ShaderToy base there lots of shaders of the same type just with minimal changes, or very-very simple ones, or just very-very dumb ones, so for real the number of normal shaders, not 40000, but much less.

Quite many shaders with video and added simple effects at the top, not of big interest too. Some just static ones, having no animation.

So for real, I think the amount of really cool and interesting shaders is about 10000, maybe less. Which is quite a lot, still.

But new ones keep coming every day, and in a few days there always a few new shaders of good quality.

@Capehill
Quote:

Yeah, that one do have:

float rand(vec2 co, float seed){
return fract(sin(dot(co.xy + seed ,vec2(12.9898,78.233))) * 43758.5453);
}

As Hans says about their rand function: "function uses operations in a manner where precision makes a difference. A simple thing such as how precise the sin() approximation is, or whether multiply-and-accumulate instructions are used instead of a * b + c results in different behavior."

I find out a few more shaders with the same error, and just going as Hans suggests by reducing multiplier deal with. For example that one work as expected on a beta of nova when reducing 11000000.0 to 11000.0: https://www.shadertoy.com/view/3s3Xz2

See it had:

float rand(float seed) {
return fract(sin(seed * 11000000.0 + 11223.12332));
}


Or another one in which I had to change "gl_FragCoord.x * 0.482635532" in dither() function on "gl_FragCoord.x * 0.48232" to make it works as expected: https://www.shadertoy.com/view/lslGR8. See:

float dither()
{
return fract(gl_FragCoord.x * 0.482635532 + gl_FragCoord.y * 0.1353412 + iTime * 100.0) * 0.008;
}

So dunno if anything can be done about those on our side to auto-fix them.

@Capehill,Daniel
If there will be some minutes of free time, maybe you can look briefly at those shaders:

https://www.shadertoy.com/view/4djGzh - just black screen
https://www.shadertoy.com/view/MsSGWz - just black screen
https://www.shadertoy.com/view/3lscDf - almost everything black, just some pieces of effect visibly
https://www.shadertoy.com/view/4djGWV - just black screen
https://www.shadertoy.com/view/Md2GDy - effect didn't renders, instead whole screen filled by some solid color, and we can see how line at bottom and some few dots in some part of screen tried to render something.

First two i report already, but 3 other ones on hold at moment, just want to be sure that all those 5 shaders didn't broken by itself. As with latest beta of Nova it start to be more offten that shaders itself buggy.

My results are the following.

https://www.shadertoy.com/view/4djGzh - black screen
https://www.shadertoy.com/view/MsSGWz - ouch, system freeze, always

For those I took a quick look at the shader code:

https://www.shadertoy.com/view/3lscDf - almost black, only a handful of rotating sphere-like entities visible. didn't spot anything critical, in theory, with certain theoretically possible N / P constant combinations some math could become undefined, but not in this config, so didn't spot bugs in the shader.
https://www.shadertoy.com/view/4djGWV - pixel garbage revealing CUs, pattern depends on mouse input (which is to be expected for all shaders which use mouse-input). Didn't spot bugs in the shader.
https://www.shadertoy.com/view/Md2GDy - solid brown-red with pixel garbage in the center and at the right edge. Didn't spot bugs in the shader.

This was with Nova 1.71. I'd say it's fine to throw'em at Hans.

@All
Need some help to understand where the issue may come.

There is a shader in question: https://www.shadertoy.com/view/lt2fDz

It didn't work on any Nova starting from 1.68 to 1.74. But, to make it works, all that we need, is to move the whole MainImage() at bottom of the source file. And then it works.

The same happens with our "Kissing Donuts" shader: https://www.shadertoy.com/view/MdBczW, which starting since 1.72 stop working and produce black screen, but, moving MainImage() again at bottom of source file make it works again.

So, need to be sure where that issue is: in Warp3dNova or somewhere else, because when one shift functions in the same source fail without changing their content, and that lead to different results probably mean some stack/heap areas corrupted where the name of functions and their bodies placed for the shader compiler.

Also, taking into account that "kissing donuts" shader works till 1.72, but then stop working, and only shifting MainImage() at bottom of file make it works again, can point out us that some bug just flying around and we have kissing donuts working before just by luck.

And that not only those 2 shaders. I find out some more, which originally produce black/grey/yellow/whatever screens instead of actual rendering but shifting functions just one or another way around without changing them, make shaders work.

Any ideas? Just to make a proper bug report.

@kas1e
Quote:
Just report it the way you just did here. It's Hans' job to extract the "why" out of this and to fix it.

@Daniel
Just want to be sure that generated SpirV already good and correct one all the time. It can be that when things shifted, generated spirv code may have issues, before even going to nova.

@kas1e
Such a basic problem in glslangvalidator is extemely unlikely (maybe even more unlikely than a bug in your favorite smart_ptr implementation ), whereas another bug in Nova is highly likely. Considering Nova's current state I'd suggest to asume that it's another Nova bug and just report it.

@Daniel
Yeah, there is : http://www.amiga.org/developer/bugreports/view.php?id=594

@Daniel
Find out another interesting shader which fails, this time small one, which uses "vec2[16] points;". I create a BZ for of course: http://www.amiga.org/developer/bugreports/view.php?id=599, but as it has arrays in and lately some work being done on in ogles2, and the whole shader is just 16 dots connected by lines, maybe this time it can be something in ogles (i very much hope, but chances are low that this is olges2's issue, I know)

@kas1e
Quote:
That's something totally unrelated. Support for arrays inside ogles2 has nothing to do with local arrays inside shaders. No, this one's for sure yet another Nova bug.

@All
As of late, I report pretty about 50 more shaders with rendering issues, want to help Hans to reduce test cases and to find out problems, so he will have no need to spend all time to experiment with.

So, the shader in question are:
https://www.shadertoy.com/view/lsXcDN

reported here with screens of bug. http://www.amiga.org/developer/bugreports/view.php?id=550

In brief, on amigaos4, the "bar" things which should be at top and bottom, instead keep bottom and top be not filled but fill the whole effect.

I pin point it now to the last string, which is:



And the issue is exactly bl.y>.50. If I change there > on <, it then works as expected. And visa-versa, if I change on win32 that > on <, it then starts to be buggy as on amigaos4 now.

The question is: what is that? An issue with handling > < in nova, or something about negative/positive values, or what?

Or maybe its related to ShaderJoy's define of iResolution.xy; (because previous that "bl" defined as : vec2 bl = fragCoord.xy / iResolution.xy;).

Any help apprecated!

PS. The same issue happens with that shader: https://www.shadertoy.com/view/Xtjyzz

There the guilti line is :



If i change there uv.u>0.85 on uv.u<0.85 (i.e. the same > on <) then it start to works as expected on amigaos4. And the same if i change on win32 it on < instead of >, it then start to show a bug like on amigaos4.

And "uv" there the same include iResolution : "vec2 uv = fragCoord.xy / iResolution.xy;"

@kas1e

Maybe issue is related to operator ^^. If you replace it by ||, then it works, right? Semantics are bit different but still.

For example I tried something like:

vec3 col = (uv.y < 0.1 ^^ uv.y > 0.9) ? vec3(0.0) : vec3(1.0);

So there should be black borders but they are white.

@Capehill
Quote:

With https://www.shadertoy.com/view/Xtjyzz it helps to change ^^ just on ||

But with https://www.shadertoy.com/view/lsXcDN , didn't help.

Quote:

Uhm, so it means that we have some general issue with the ^^ operator? Can we probably create an issue like "major issue with ^^ operator", and as an example of the bug put that test case:



?

@Capehill
Oh damn, found other shaders suffer with this ^^ issue. For example:

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

Once I replaced there on line 33 ^^ on || - it then works!

I Will check more reports, seems we found some major stuff.