Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
78 user(s) are online (55 user(s) are browsing Forums)

Members: 0
Guests: 78

more...

Headlines

 
  Register To Post  

« 1 2 (3) 4 5 6 »
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Quote:
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

Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Daniel
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.


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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@Daytona675x

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.


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.

Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Yes, that's what I meant.

@Capehill
Quote:
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.


Edited by Daytona675x on 2020/6/8 10:18:01
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@All

Another set of shaders which produce white/black/grey screen and render nothing. As example this simple one:

https://www.shadertoy.com/view/WtfyzM

void mainImageout vec4 fragColorin 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<= 70; ++i)
    {
      
float f float(i)/120.;
      
float x p.cos(f*9.)*.25;
      
x*k;
      
float y p.f;
      
+= -cos(x+f*18.iTime*.5)*smoothstep(1.,.0,abs(x))*.1;
      
float m smoothstep(t,-t,y);
      
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 ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@kas1e
smoothstep is a basic GLSL function.

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

Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Daniel,Capehill

Found some _very_ simple shader, which reduced to just 2 strings, which had visuall issues. Check this out:

void mainImageout vec4 oin vec2 U )
{
    
vec3 u vec3(U/100.0,100.0);
    
o=max(o*.95,cos(2.*dot(u,u)*2.0*.1+vec4(.3,.1,0,0)));
}



WIN version:

Resized Image

AOS4 version:

Resized Image


The simplest possible :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@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


Edited by Daytona675x on 2020/6/9 10:06:27
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Daniel

Yeah, you are right! Create bz with your finding:

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

@Hans

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 ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@kas1e

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.

Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@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
Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@Daytona675x

Good finding. I guess I will remove the useless fragment colour initialization in Shaderjoy because Shadertoy mainImage uses "out".

Quote:

void mainImage( out vec4 fragColor, in vec2 fragCoord )

Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@All
Yeah, Hans also close issue. Good that it were false alarm :)

Another issue i want to discuss, is something with "for" loop happens still. For example , take a look at that shader:

https://www.shadertoy.com/view/tlXcR4

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 :

https://www.shadertoy.com/view/wsBfDw

There we have that "for" loop:

for (float i 0.3.i++) {
        
+= 1.0 abs(mod(st.st.x0.1 i) * 1000.) * 1.;
        
+= 1.0 abs(mod(st.st.x0.5 i) * 10.) * 1.;
    }


And we have black screen then. But if we do it like:

//for (float i = 0.; i < 3.; i++) {
        
+= 1.0 abs(mod(st.st.x0.1 1.0) * 1000.) * 1.;
        
+= 1.0 abs(mod(st.st.x0.5 1.0) * 10.) * 1.;

        
+= 1.0 abs(mod(st.st.x0.1 2.0) * 1000.) * 1.;
        
+= 1.0 abs(mod(st.st.x0.5 2.0) * 10.) * 1.;

        
+= 1.0 abs(mod(st.st.x0.1 3.0) * 1000.) * 1.;
        
+= 1.0 abs(mod(st.st.x0.5 3.0) * 10.) * 1.;

    
//}


Then effect works.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@kas1e

Interestingly, "Stainless"

Quote:

produces a black display also on my Win7 / Radeon combo. Unrolling the for-loop cures it.

Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@Capehill

Yep, confirmed, unrolling for or:
float i 0.;
    do{
    
//for (float i = 0.; i < 3.; i++) {
        
+= 1.0 abs(mod(st.st.x0.1 i) * 1000.) * 1.;
        
+= 1.0 abs(mod(st.st.x0.5 i) * 10.) * 1.;
    
//}
        
++i;
    }while(
i<3.);


makes it work.

Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@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


Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Daniel
Do you think that one also broken: https://www.shadertoy.com/view/tlXcR4

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) :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Not too shy to talk
Not too shy to talk


See User information
@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.


Edited by Daytona675x on 2020/6/10 6:17:52
Go to top
Re: Warp3DNova shader bugs thread
Just can't stay away
Just can't stay away


See User information
@Daytona675x

Nice find again regarding division by zero.

Maybe we need to create Shadertoy accounts and start reporting these issues :)

Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@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:

https://www.shadertoy.com/view/wsBfDw
https://www.shadertoy.com/view/wsSBWm
https://www.shadertoy.com/view/tsBfDw
https://www.shadertoy.com/view/3s2Bzy
https://www.shadertoy.com/view/td2fDm


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

#define PI 3.141592
#define MAXITER 100

float sdSphere(vec3 posfloat rad) {
    
    
//vec2 ang = vec2(atan(pos.y / length(pos.xz)), vec2(pos.z / pos.x));
    
vec3 norm normalize(pos);
    
//Sphere UV mapping
    //vec2 uv = vec2(0.5 + atan(norm.z/norm.x)/(2.0*PI), 0.5 - asin(norm.y)/PI);
    
vec2 uv vec2(0.5 atan(norm.z/norm.x)/(2.0*PI), 0.5 asin(norm.y)/PI);
    
uv *= 30.0;
    
    
float bump sin(uv.x)*sin(uv.y);
    
//bump = abs(bump);
    //float bump = sin(pos.x*10.0)*sin(pos.y*10.0)*sin(pos.z*10.0) * 0.5 + 0.5;
    
bump pow(bump5.0);
    
bump *= 5.0;
    
bump min(1.0bump);
    
bump /= 5.0;
    
//bump = 0.0;
    
return length(pos) - rad bump;
}

float sdPlane(vec3 pos) {
    return 
pos.y+sin(pos.x)+sin(pos.z);
}


float sceneDist(vec3 pos) {
    
    
vec3 rep mod(pos+2.04.0)-2.0;
    
//vec3 rep = pos;
    
float sphere1 sdSphere(rep-vec3(0.00.00.0), 1.0);
    
float d sphere1;
    
//float sphere2 = sdSphere(pos-vec3(0.0, 0.75, 0.0), 0.1);
    //d = min(d, sphere2);
    //float sphere3 = sdSphere(pos-vec3(0.0, 0.0, 0.75), 0.1);
    //d = min(d, sphere3);
    
float plane sdPlane(pos-vec3(0, -10.00));
    
min(dplane);
    
*= 0.6;
    
//return min(sphere1, sphere2);
    
return d;
}

mat3 rotation(vec2 angles) {
    
mat3 id mat3(100010001);
    {
        
vec3 u vec3(cos(angles.x), 0sin(angles.x));
        
vec3 v vec3(010);
        
vec3 w vec3(-sin(angles.x), 0cos(angles.x));
        
id id mat3(uvw);
    }
    {
        
vec3 u vec3(100);
        
vec3 v vec3(0cos(angles.y), -sin(angles.y));
        
vec3 w vec3(0sin(angles.y), cos(angles.y));
        
id id mat3(uvw);
    }
    return 
id;
}
void mainImageout vec4 fragColorin vec2 fragCoord )
{
    
    
vec2 lookingAngle vec2(iTime, (sin(iTime)*0.5+0.5)*-PI/2.0*0.5);
    
//vec2 lookingAngle = vec2(iTime, 0);
    //lookingAngle.x = iMouse.x / 100.0;
    //lookingAngle.y = -iMouse.y / 100.0;
    
    
mat3 rot rotation(lookingAngle);
    
    
vec3 pos rot vec3(001);
    
pos *= -10.0;
    
    
// Normalized pixel coordinates (from -1 to 1)
    
vec2 uv fragCoord/iResolution.xy 2.0 1.0;
    
uv.*= iResolution.iResolution.y;
    
vec3 dir rot normalize(vec3(uv.xy2.5));
    
    
bool collide false;
    
int i;
    for (
0MAXITER && !collidei++) {
        
float dist sceneDist(pos);
        if (
dist 0.0001)
            
collide true;
           if (
dist 1000.0)
        {
            
i=MAXITER;
            break;
        }
        
pos += dir dist;
    }
    
vec3 col vec3(float(i) / float(MAXITER));
    
bool lost float(i) > 0.8*float(MAXITER);
    
/*
    if (collide)
        col = vec3(1.0);
    else
        col = vec3(0.0);
*/
    
    //if (lost) col.x = 0.0;
    //col = dir.zzz;

    // Output to screen
    
fragColor vec4(col,1.0);
}


WIN version:

Resized Image

AOS4 version:

Resized Image


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 2 (3) 4 5 6 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project