Imho also not worth , because it mean take manual actions.
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:
can be unitialized variable set to 0 cause any issues in compare with being random as it now ?
No. It has no negative side-effects (other than a certain performance loss, if that's measurable is another question).
Quote:
I mean, of course, shaders can be buggy and rely on undifened behaviours, but will setting unitialized value to 0 , cause any problems for any other possible shaders ? Imho no ? Then if no, why not ?:)
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
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.
Ah, if you mean it can be used on the context creation for ogles2, just like we have ability to have auto-handle of bitmap resizing , then sure, one more flag will made it only better. And shadertoy may use it as well later.
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.
Yeah, I agree it's not a Nova issue. But somekind of an "offline" analysis using some GLSL validator might be possible. Should check what is out there... Khronos at least has lots of software on Github.
But somekind of an "offline" analysis using some GLSL validator might be possible.
Offline sucks
Quote:
Should check what is out there... Khronos at least has lots of software on Github.
AFAIK they don't support that feature.
Quote:
myself: "And such a analysis is not trivial and not for free"
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.
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
vec2 p = (fragCoord-.5*iResolution.xy)/iResolution.y;
vec3 col = vec3(0.);
float t = .005;
float k = 3.;
float d = 0.;
for(int i = -80; i <= 70; ++i)
{
float f = float(i)/120.;
float x = p.x + cos(f*9.)*.25;
x = x*k;
float y = p.y + f;
y += -cos(x+f*18.+ iTime*.5)*smoothstep(1.,.0,abs(x))*.1;
float m = smoothstep(t,-t,y);
d = mix(d,m,m);
}
col += d;
fragColor = vec4(col,1.0);
}
On AOS4 just white screen.
I assume it can be again that "for" loop (because i already found few shaders, where "for" still broken). Or negative values ?
EDIT: is smoothstep() is something from GLSL standard ? Can it be issues in ?
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 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
I wrote it in that BZ, but question are: should we keep posting rendering issues bugs (there many in end), so you will fix them in current register allocator, or, if you will work on new / rewriten version with spiling and stuff (so it will auto fixes and for rendering bugs, and for low amount of sgprs/vgprs), then we just hold the horses, and wait for it ?
This 2-line shader also seems to assume that "o" is initialized by something before calling mainImage. Shadertoy iOS application initializes only the alpha component of the output fragment. I don't know whether Shadertoy web app initializes the fragment colour or is it Windows OpenGL drivers that does that.
@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)
Edited by Daytona675x on 2020/6/9 10:02:26 Edited by Daytona675x on 2020/6/9 10:03:43 Edited by Daytona675x on 2020/6/9 10:07:58
On os4 , it just produce "green" screen. Nothing renders or moves as it should happen. If i comment out "for(float l = 10.0; l > 0.0; l -= 1.0){" , and just do "float l = 10.0;" , then while of course effect changes, still, it start to renders on os4 and moves.
Another shader which also seems share "for" issue, is that one :
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:
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
Just was about to made a BZ about where put 2 those shaders about "for" issues, and one of them is broken..
Intersting also, how costly it will be to add "unitialized variable = 0" not from ogles2 side, but from Nova ? Because testing many shaders (and they all didn't seems false positive with your last libs), many of them do use unitialized variables, i mean many (and they didn't seems false positive in end of all, as i found in the shader's codes unitialized ones all the time)
Quote:
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
Today i found shader which ask for more than 2000 VGPRs (yeah, 2 thousands) :)
@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:
Intersting also, how costly it will be to add "unitialized variable = 0" not from ogles2 side, but from Nova ?
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:
Because testing many shaders (and they all didn't seems false positive with your last libs), many of them do use unitialized variables
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.
@Daniel, Capehill There is another shaders from the same author, with the same "divide by zero" issue, all of which fixed when replaced for loops be started from 1 to 4 instead from 0 to 3. There they are:
Also another shader to discuss, maybe from visuall look some assumtion can be done so i can made proper BZ about. So, shader: https://www.shadertoy.com/view/tsjBRw
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
