Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
70 user(s) are online (52 user(s) are browsing Forums)

Members: 0
Guests: 70

more...

Headlines

 
  Register To Post  

OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
Having a few problems compiling shaders. For one, multiplying two mat4 matricies does not seem to work at all.

layout(location 0in vec3 vertexPosition_modelspace;
uniform mat4 M;
uniform mat4 V;
...

vec3 vertexPosition_cameraspace = ( vec4(vertexPosition_modelspace,1)).xyz;


This code will work sometimes, but after a few similar calculations it will not compile.

layout(location 0in vec3 vertexPosition_modelspace;
uniform mat4 MV;
...

vec3 vertexPosition_cameraspace = ( MV vec4(vertexPosition_modelspace,1)).xyz;


This is the vertex shader that works in Windows, with just the '#version 310 es' switched in.

#version 310 es
layout(location 0in vec3 vertexPosition_modelspace;
layout(location 1in vec3 colourRGB;
layout(location 2in vec3 vertexNormal_modelspace;

out vec3 RGB;

out vec3 Position_worldspace;
out vec3 Normal_cameraspace;
out vec3 EyeDirection_cameraspace;
out vec3 LightDirection_cameraspace;

uniform mat4 MVP;
uniform mat4 M;
uniform mat4 V;
uniform vec3 LightPosition_worldspace;

void main()
{
    
gl_Position =  MVP vec4(vertexPosition_modelspace,1);

    
Normal_cameraspace = (vec4(vertexNormal_modelspace,0)).xyz;
    
    
Position_worldspace = (vec4(vertexPosition_modelspace,1)).xyz;

    
vec3 vertexPosition_cameraspace = ( vec4(vertexPosition_modelspace,1)).xyz;
    
EyeDirection_cameraspace vec3(0,0,0) - vertexPosition_cameraspace;

    
vec3 LightPosition_cameraspace = ( vec4(LightPosition_worldspace,1)).xyz;
    
LightDirection_cameraspace LightPosition_cameraspace EyeDirection_cameraspace;    

    
RGB colourRGB;
}

Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
Can compile the shader with glslangValidator with no problems, but they just wont compile through the ogles2 library. Also having any #version statement in the fragment shader stops it from compiling through ogles2 library at all.

Go to top
Re: OpenGL ES shader compiler problems.
Quite a regular
Quite a regular


See User information
Maybe it's not supported?

Retired
Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
@AmigaBlitter

Maybe I should try turning it on and off.

Go to top
Re: OpenGL ES shader compiler problems.
Home away from home
Home away from home


See User information
@Caras
Quote:
Having a few problems compiling shaders. For one, multiplying two mat4 matricies does not seem to work at all.

Won't compile? Or compiles but doesn't work? What error messages are in the compile log?

Quote:
This code will work sometimes, but after a few similar calculations it will not compile.

What's in the compile log?

Quote:
Also having any #version statement in the fragment shader stops it from compiling through ogles2 library at all.

You should submit a bug report to Daniel (the ogles2.library author).

Please submit bug reports for Warp3D Nova (& other enhancer CD items) to the amigadeveloper.com bug tracker instead of posting them to forums. You'll find it here: http://amigadeveloper.com/bugreports/login_page.php

I can't go round all forums constantly looking for bug reports, and bugs posted here easily get lost.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
@Hans

All these problems are that they wont compile. Where is the compiler log?

I wanted to check and see if I missed anything obvious before submitting a bug report. I guess I'll go ahead and do that.

Go to top
Re: OpenGL ES shader compiler problems.
Home away from home
Home away from home


See User information
@Caras
Quote:
All these problems are that they wont compile. Where is the compiler log?

glGetShaderInfoLog() should get it, or glGetProgramInfoLog() if it fails at linking stage.

EDIT: If something compiles under glslangvalidator, it's worth checking the compiled *.spv file it with W3DNShaderInfo (use the -v option to get full debug info). If W3DNShaderInfo spits out error messages, then it's the W3DN_SI driver's compiler that's causing it to fail. Otherwise the problem is likely in the ogles2.library.

Hans


Edited by Hans on 2017/1/26 2:54:06
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
@Hans

The error seems to be coming from Warp3D Nova.

"Need 114 SGPRs, which exceeds the maximum of 104."

Go to top
Re: OpenGL ES shader compiler problems.
Home away from home
Home away from home


See User information
@Caras
Quote:
"Need 114 SGPRs, which exceeds the maximum of 104."

I was hoping it would take a while before someone hit that limit. Writing a better register allocator is on the to-do list, but will take time.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
@Hans

Ok, I was able to remove a line I didn't realise I didn't need and it fits under the limit now :)

Go to top
Re: OpenGL ES shader compiler problems.
Just popping in
Just popping in


See User information
Hi Hans,
i have the same error:
"Need 124 SGPRs, which exceeds the maximum of 104."
What changes can I make to the fragment shader code to avoid the error?

Go to top
Re: OpenGL ES shader compiler problems.
Not too shy to talk
Not too shy to talk


See User information
@AlfredOne
Hans seems to be too busy to answer, I'll try based on my experiences and observations instead.
Unfortunately this has not been fixed during the last 3,5 years.
It's hard to give any precise info on what to change without seeing your shader code, but there are some rule of thumbs and hints I can give.

I suggest to get your hands on a standalone SPIR-V compiler (glslangValidator) and a SPIR-V disassembler (I use the windows spirv-dis.exe, was too lazy to try to port that to aos4 so far). Taking a look at the disassembly (no worries, it's pretty easy to grasp) of your shader will help you to get an idea about the ~ overall register requirements and where your shader "loses" the most registers, in case of Nova. The reason is:

SPIR-V has no concept of registers. For many operations it simply introduces new "dummy" variables to hold intermediate calculation results or to pass function parameters around. And it doesn't reuse such variables, it simply doesn't care and adds new ones. Nova should of course have a register manager which doesn't do that but instead transforms those dummy variables into true temporary register usage. Unfortunately that isn't the case. Which is why until now and right now the first rule of thumb is:

Nova's register demands are roughly equivalent to the SPIR-V source's variable usage.

Probably the biggest reason for register-waste are function calls, the more parameters the function has the worst. This is because SPIR-V creates variables for every parameter passed. If you want to make Nova's shader translator to give up real fast then have many functions and / or functions with many parameters and / functions that are called multiple times.
Therefore try to avoid this. If your function isn't recursive and reasonably small, consider making it a #define. If your function has tons of single float parameters, consider packing those into vec4 or so. Or maybe, as a last resort and if possible without side-effects, work with global variables instead.

It may also help if you keep the amount of true named non-temporary variables low in general and also try to reuse your own temporary variables instead of coming up with new ones.

As a last resort, if you run out of ScalarGPRs (stuff like "float") then try to use VectorGPRs (stuff like "vec2") instead and vice versa.

Also, try to avoid arrays, Nova is particularly wasteful with those. Of course that's often not an option.

Hope that helps a bit, cheers!


Edited by Daytona675x on 2020/7/22 10:37:59
Edited by Daytona675x on 2020/7/23 8:41:12
Go to top

  Register To Post

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project