Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
65 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 65

more...

Headlines

 
  Register To Post  

(1) 2 3 4 ... 6 »
Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
To avoid deraling shaderjoy's thread, and to simplify creating/updating bug reports later, just create that thread where problematic ones can be discussed.

So, first set of shaders of popular error are:

Matrix element 0's type (unknown) doesn't match the matrix's element type (Float) : BZ 483 (http://www.amiga.org/developer/bugreports/view.php?id=483)

As can be see, just such simple shader fail:

#version 310 es

mat2 m = mat2(1,2,3,4);

void main(void)
{
}


Anyone have idea how for the time being it can be workarounded ? It's quite offten we have such kind of constructs in the shaders, like:

mat3 m = mat3 (
0.59719, 0.07600, 0.02840,
0.35458, 0.90834, 0.13383,
0.04823, 0.01566, 0.83777
);

or

mat2 rot;
rot=mat2(1,2,3,4);

In all those cases we fail with that error. Maybe there a way for time being to workarond it somehow ?

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

1) Try adding 'f' suffix after each number.
2) Try using 3 vec3s to construct mat3: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Matrix_constructors


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


See User information
@Capehill

Quote:

1) Try adding 'f' suffix after each number.


mat2 m = mat2(1.f,2.f,3.f,4.f); didnt work too :(

Quote:

2) Try using 3 vec3s to construct mat3: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Matrix_constructors


Tried just this kind of test:

mat3 theMatrix;
theMatrix[1] = vec3(3.0, 3.0, 3.0); // Sets the second column to all 3.0s
theMatrix[2][0] = 16.0; // Sets the first entry of the third column to 16.0.

It even didn't compiles by glslangvalidator. Saying ERROR: 3:1 '' : syntax error, unexpected IDENTIFIER

Same if i do just:

mat3 theMatrix;
theMatrix[1].yzx = vec3(3.0, 1.0, 2.0);

Maybe those din't work with just #version 310 es, and need something else to be added..

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
Oh, they should be inside of function so yeah, that one compiles fine:

#version 310 es

mat3 theMatrix;

void main(void)
{
theMatrix[1] = vec3(3.0, 3.0, 3.0); // Sets the second column to all 3.0s
theMatrix[2][0] = 16.0; // Sets the first entry of the third column to 16.0.

}

Will check if it works in actual shaders.

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

I'm using the following vertex shader in Fractal Nova:

#version 310 es

in layout(location 0vec2 vertPos;
in layout(location 1vec2 textureCoord;

uniform layout(location 0float angle;
uniform layout(location 1float zoom;
uniform layout(location 2vec2 point;

out vec2 texCoord;

void main()
{
    
texCoord vec2(textureCoord.3.5textureCoord.2.0);

    
mat2 zoomMat mat2(zoom0.00.0zoom);
    
mat2 rotationMat mat2(cos(angle), -sin(angle), sin(angle), cos(angle));

    
vec2 p rotationMat zoomMat * (vertPos point);

    
gl_Position vec4(p0.01.0);
}


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


See User information
@Capehill
Vertex, but not fragment one, maybe that the issue (exactly in fragment ones). Because just pure this one didn't compiles :

#version 310 es

float a,b,c,d;

void main(void)
{
mat2 m = mat2(a,b,c,d);
}

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@kas1e

Quote:
In all those cases we fail with that error. Maybe there a way for time being to workarond it somehow ?

Unlike C, GLSL does *NOT* do implicit casting between number types. So, mat2(1,2,3,4) is wrong; it *must* be mat2(1.0f, 2.0f, 3.0f, 4.0f).

The GLSL compiler shouldn't have let that through.

EDIT: The implicit casting rule seems to have been relaxed in newer GLSL versions. Integer to float is now okay. You could try setting #version 140 or similar at the top of the source file.

This may be a GLSLangValidator bug. It should be handling the casting of constants when it generates SPIR-V code. Guess I'll have to make a workaround...

Quote:
@Capehill
Vertex, but not fragment one, maybe that the issue (exactly in fragment ones). Because just pure this one didn't compiles :

#version 310 es

float a,b,c,d;

void main(void)
{
mat2 m = mat2(a,b,c,d);
}

You're assigning uninitialized variables to a matrix, whereas Capehill is assigning uniform variables.

What error message do you get?

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Hans
Quote:

Unlike C, GLSL does *NOT* do implicit casting between number types. So, mat2(1,2,3,4) is wrong; it *must* be mat2(1.0f, 2.0f, 3.0f, 4.0f).

The GLSL compiler shouldn't have let that through.

EDIT: The implicit casting rule seems to have been relaxed in newer GLSL versions. Integer to float is now okay. You could try setting #version 140 or similar at the top of the source file.

This may be a GLSLangValidator bug. It should be handling the casting of constants when it generates SPIR-V code. Guess I'll have to make a workaround...


Yeah, that the first issue about probabaly. Just with marixes we find it by luck. At least in all shaders of late i find which use matrixies all of them didn't provide .f suffix, all works without.

But our real issue isn't that one. Issue we have all around shaders is one from BZ 483. For example if we compile that one:


#version 310 es

void main(void)
{
mat2 m = mat2(1,2,3,4);
}


we have "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)" from Nova (glslangvalidator pass it ok). With #version 140 its the same.

If we made it like:

#version 310 es

void main(void)
{
mat2 m = mat2(1.0f,2.0f,3.0f,4.0f);
}

Then it still the same issue: "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)". The same with #version 140. And it the same ok with glslangvalidator (be it 310 es or 140), and fail when pass spirv to nova.

So it didn't looks like "f" issue there, while probabaly it still also issue too, just minor one.

Quote:

You're assigning uninitialized variables to a matrix, whereas Capehill is assigning uniform variables.

What error message do you get?


If i compile it like :

#version 310 es

float a,b,c,d;

void main(void)
{
mat2 m = mat2(a,b,c,d);
}

So to use unasigned values (which probabaly should be 0.0f by deafult ?), then error i got are :

INTERNAL ERROR: SOP1 instruction can't have VGPR source or desitnation registers S_MOV_B32 sDst(SGPR9) src0(VGPR2).

But that error are reasson for another bug report, as this one happens from time to time on other shaders, not very offten, but still. But really importan one (by amount of failed shaders), is this "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)", for which probabaly that "f" thing need to be relaxed as you say, but even with "f" we have that error.
I.e. that test case fail as well as i say:

#version 310 es

void main(void)
{
mat2 m = mat2(1.0f,2.0f,3.0f,4.0f);
}


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
#version 310 es

out vec4 FragColor;

void main()
{
  
float f 1.0f;

  
mat2 m mat2(f); // Works
  //mat2 n = mat2(1.0f); // Doesn't work

  
FragColor vec4(1.0);
}


The error that I get is something about matrix element's type being Unknown when it should be Float.

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


See User information
@Capehill
Quote:

The error that I get is something about matrix element's type being Unknown when it should be Float.


Yes, that the bug i tried to explain: "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)", BZ 483 : http://www.amiga.org/developer/bugreports/view.php?id=483

And strange it did happens and with ".f" and without.

It's like both mat2 and mat3 , didn't take floats arguments at all, be them shown with .f or without and always threaten. But when you give variable as argument , then all fine.


Edited by kas1e on 2020/5/24 18:54:36
Edited by kas1e on 2020/5/24 18:55:15
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
@Hans
Quote:
This may be a GLSLangValidator bug.

No, doesn't look like this.

Quote:
It should be handling the casting of constants when it generates SPIR-V code. Guess I'll have to make a workaround...

It does. You can disregard that idea. A simple test reveals that whether you use 1.0 or 1 or 1.0f doesnt matter. glslangvalidator_redux and ogles2's internal glslangvalidator produce the same SPIR-V output in all cases. And if you run that through a disassembler you can see that it correctly creates float constants.

Quote:
You're assigning uninitialized variables to a matrix

Which is also legal (although I wonder why it's allowed). glslangvalidator produces and uses 4 float variables, just as to be expected.

@kas1e
Quote:
So to use unasigned values (which probabaly should be 0.0f by deafult ?)

No, undefined is undefined. If you assign fix values to those glslangvalidator will of course generate constants.

Quote:
And strange it did happens and with ".f" and without

Not strange at all, it's all converted to the very same floats, see above.

All in all there apparently is no problem on the GLSL -> SPIR-V side or in the generated SPIR-V, Nova simply has problems handling correct SPIR-V sometimes.


Edited by Daytona675x on 2020/5/24 21:17:42
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@kas1e

Quote:
If we made it like:

#version 310 es

void main(void)
{
mat2 m = mat2(1.0f,2.0f,3.0f,4.0f);
}

Then it still the same issue: "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)". The same with #version 140. And it the same ok with glslangvalidator (be it 310 es or 140), and fail when pass spirv to nova.

Okay, Warp3D Nova bug confirmed.


Quote:
So to use unasigned values (which probabaly should be 0.0f by deafult ?)

No. Uninitialized variables are uninitialized.

Quote:
, then error i got are :

INTERNAL ERROR: SOP1 instruction can't have VGPR source or desitnation registers S_MOV_B32 sDst(SGPR9) src0(VGPR2).

Thanks. So it's a problem with the generated code. Please post the full compiler log in the bug report.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Hans
Quote:

Thanks. So it's a problem with the generated code. Please post the full compiler log in the bug report.


Maybe create another bug-report exactly about those "SOP1 instructions can't have VGPR source or destination" ? As there some other shaders which bring that error.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@kas1e
Quote:
Maybe create another bug-report exactly about those "SOP1 instructions can't have VGPR source or destination" ? As there some other shaders which bring that error.

Not sure what you mean. Yes, there should be a separate bug report for each different issue. I'm just asking you to include the complete compilation log.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@Hans
I mean that there we have 3 separate issues then:

1). need relaxing about "f", so things like

mat2 m = mat2(1,2,3,4) will be the same as
mat2 m = mat2(1.0f,2.0f,3.0f,4.0f)

2). That one about "Matrix element 0's type (unknown) doesn't match the matrix's element type (Float)". BZ about which already created : BZ 483 (http://www.amiga.org/developer/bugreports/view.php?id=483)

3). Fail to compile with "SOP1 instructions can't have VGPR source or destination" when use unasigned values.


So then i need to create 2 more bugreports first one and third one. And update second one a bit

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
Quote:
1). need relaxing about "f", so things like
mat2 m = mat2(1,2,3,4) will be the same as
mat2 m = mat2(1.0f,2.0f,3.0f,4.0f)

Despite what Hans said somewhere above, there is no such issue. Both syntaxes are valid, both are handled by glslangvalidator / ogles2.lib, both result in the very same valid SPIR-V code sent to Nova.
The other two things however are two apparently seperate Nova bugs.

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


See User information
@Daniel
Ah so, less to fix then. If ogles2 and glsnalgvalidator already send the same code then all fine.

Will update then reported one, and create new one about unasigned values.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@All
Updated http://www.amiga.org/developer/bugreports/view.php?id=483 about "matrix float" issue (pointing out that .f make no difference, and added verbose output).

Now, want to create correct bz report about those "Uninitialized variables" error we have, and then, found in my log some more shaders which fail with the kind of the same , but a little bit different error. I.e.:

"INTERNAL_ERROR: SOP2 instuction can't have VGPR source or destination registers"

(in our test case with matrixes at top, we have "SOP1 instruction can't have VGPR source or destination registers". I.e. SOP1 and SOP2).

There is that small test shader which bring us SOP2 issue:

#define PI 3.14159
#define WIDTH .1

// Check if a point is within the width of a line
bool checkLine(vec2 uvfloat f_xfloat width){
    return 
abs(uv.y-f_x) < width;
}

void mainImageout vec4 fragColorin vec2 fragCoord )
{
    
//amplitude of sine wave
    
float a=sin(iTime)/8.0;
    
//a=abs(a);
    
    //rate it spins at
    
float rotRate=iTime;
    
    
vec2 uv=(2.0*fragCoord)/iResolution.xy-1.0;
    
    
//polar coordinates
    
vec2 pc=vec2(
        
atan(uv.y/uv.x),
        
length(uv)
    );
    
    
//multiply the sine wave
    
pc.x=pc.x+rotRate;
    
    
float f_x=0.5+a*sin(8.0*pc.x);
    
    if(
checkLine(pc,f_x,WIDTH))
        
fragColor=vec4(1);
    else
        
fragColor=vec4(0,0,0,1);
        
}


There we didn't use any matrisies. So issue is not " assigning uninitialized variables to a matrix". From the shader i post i didn't see any matricies, it's small enough and still it fail with that "SOP2 instructions can't have VGPR source or destination".

Any ideas why the same error (just with SOP2 and not SOP1) happens there, and is it the same error with the same roots which can fits in the same bug report ?

@Capehill
Oh, it seems be the same issue you meet with "boolean" errors in http://www.amiga.org/developer/bugreports/view.php?id=479, in your last boolout3 example.

But need to understand if it happens because of unitialized value as well , or it just absolutly different issue.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Warp3DNova shader bugs thread
Home away from home
Home away from home


See User information
@All
In meanwhile there is another small shader which renders wrong.

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

There is simplified version of that shader which still give issue:

vec4 circle(vec2 uvvec2 posfloat radvec3 color) {
    
float d length(pos uv) - rad;
    return 
vec4(color1.0 -0.01);
}

void mainImageout vec4 fragColorin vec2 fragCoord )
{
    
// Normalized pixel coordinates (from 0 to 1)
    
vec2 uv fragCoord/iResolution.xy;
    
    
// Time varying pixel color
    
vec3 col 0.5 0.5*cos(iTime+uv.xyx+vec3(0,2,4));
    
    
float radius 0.5 iResolution.y//Size of circle

    
vec4 myCircle circle(fragCoord.xyiMouse.xy radiuscol); //My circle (iMouse.xy * uv) / 0.5
    
    // Background layer
    
vec4 background vec4(0.820.870.891.0); //Simple background

    // Output to screen
    
fragColor mix(backgroundmyCirclemyCircle.a);

}



On win32 it renders like this (press open in new tab for fullsize):

Resized Image

See there on the right-bottom "sun" visibly. The shader change colors of the sun and of background around.

Now, that how shader looks like on our side:

Resized Image

There no sun visibly, and only background filled by color which changes.

Colors seems ok and as expected to be (at least visually looks ok), just screenshots taken in different times. What is not expected, is that there no "Sun" at all on our side and no split on different parts. Like everything in one single area.

Seems it again something about return values ? At least we can see there 1 helper function called "circle" (which is the "sun"), and we didn't see it, meaning that return values wrong.


Edited by kas1e on 2020/5/27 7:19:41
Edited by kas1e on 2020/5/27 7:23:14
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
Quote:
Maybe again something about return values

Your asumption seems to be correct (could also be function parameters being corupted).
I modified the shader to not use the circle function but inlined that code:

// vec4 myCircle = circle(fragCoord.xy, iMouse.xy , radius, col); //My circle (iMouse.xy * uv) / 0.5
    
float c_d=length(iMouse.xy-fragCoord.xy)-radius;
    
vec4 myCircle=vec4(col,1.0-c_d*0.01);

Then it works.
That's a fatal error. Return values (or function parameters (or even general variables??)) not being even near reliable is a show-stopper. This should have the top priority on the Nova fix list!

Go to top

  Register To Post
(1) 2 3 4 ... 6 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project