To avoid deraling shaderjoy's thread, and to simplify creating/updating bug reports later, just create that thread where problematic ones can be discussed.
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
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.
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.
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); }
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
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.
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.
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.
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.
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.
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 uv, float f_x, float width){
return abs(uv.y-f_x) < width;
}
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
//amplitude of sine wave
float a=sin(iTime)/8.0;
//a=abs(a);
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 ?
// Output to screen
fragColor = mix(background, myCircle, myCircle.a);
}
On win32 it renders like this (press open in new tab for fullsize):
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:
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
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:
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!
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
