Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
53 user(s) are online (23 user(s) are browsing Forums)

Members: 1
Guests: 52

Paul, more...

Support us!

Recent OS4 Files
OS4Depot.net




(1) 2 3 4 »


Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1065
@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


   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1065
@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);
}


   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@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
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1065
#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.

   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 357
@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
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@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
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@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
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 357
@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.

   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6324
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Warp3DNova shader bugs thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 357
@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!

   Report Go to top


(1) 2 3 4 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project