OpenGL ES shader compiler problems.

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



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



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

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.

Maybe it's not supported?

@AmigaBlitter

Maybe I should try turning it on and off.

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

Quote:
What's in the compile log?

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

@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.

@Caras
Quote:
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

@Hans

The error seems to be coming from Warp3D Nova.

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

@Caras
Quote:
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

@Hans

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

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?

@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!