I have a fairly complex shader. It runs fine in the editor, it runs fine on newer Android devices…it only implements basic arithmetic/bitwise functions for the most part, but it does incorporate a variety of nested loops, functions, etc - so it’s not exactly “simple”.
The issue is that when I build and run my game on an older Android device (OnePlus 8), the on-device shader compilation fails (for both OpenGLES and Vulkan) with the following error:
GLSL link error: Assertion failed: false && “PSEUDOIMUL32 must not be seen here” (the Vulkan error has different wording but still mentions “PSEUDOIMUL32” as the cause)
There is only one place on the entire internet, from what I’ve been able to find, where this error is mentioned…it’s in another thread on this Unity forum (Shader link error: "Assertion failed: false && "PSEUDOIMUL32 must not be seen here") and there was no resolution or found cause (the user who asked about it eventually surmised that it was happening due to long shader compile times - however, my shader compiles in about 3-4 seconds…not very long).
How do I even begin to debug this? I searched every file in the Unity install directory for the string “PSEUDOIMUL32” and got no results…and the only other place that term appears on the internet is in the other thread I mentioned. The term doesn’t appear in my game’s shader cache or any other file or Unity github repo, etc. So what does it mean and what would cause this assert? What is even generating the assert? Unity’s compiler? Android’s compiler?
Hi, I’m the author of the issue you referenced.
I found that “PSEUDOIMUL32” has to do with SPIRV which is the intermediate language of Vulkan. If it takes your shader 3-4 seconds to compile I’d assume it could very well be because of a timeout and you can actually test this pretty easily by changing the shader compiler. There’s a newer one which is in the works in Unity. It’s still experimental and got flaws but for me it sped up compilation times by at least x10.
You can read all about it and how to use it here
Btw I ended up not using it because it messed up the Metal compilation, changed all half variables to float (I use my shader for both mobile platforms). I just simplified my shader a lot and moved a ton of logic to the CPU instead.
Hey Shaggy21,
I guess I should have originally clarified…the few seconds of compilation time is in the Editor as it’s making all the variants…on the device the individual variants take probably less than a second each to compile (or at least, fail compiling). If I jiggle a few of the functions (disabling some key parts of my algorithm(s)) I can get it to compile without issue in roughly the same amount of time (but then it doesn’t work because I disabled things). The “problematic” areas of the shader are pretty benign (some trivial function calls that do basic arithmetic) which is why this is such a mystery. I thought “PSEUDOIMUL32” maybe refers to 32-bit integer multiplication of some sort (using floats, hence “pseudo”)…but even if I switch all my arithmetic in the problematic areas of the shader to floats I still get the assert.
I tried compiling the shader using DXC/Vulkan but Vulkan reports the same error on-device. So whatever bytecode is being generated is similar/same between FXC and DXC. Unfortunately I don’t know enough about shader bytecode to debug it directly, and the error message is so cryptic I don’t even know where to start looking (and the shader cache files are 7k lines long, so a big haystack to go looking for a needle)…
If a Unity dev could chime in and report what part of the compiler is generating that assert in the first place, that would be a much better starting point to track down why it’s happening…
1 Like
This is a linking error from the GPU driver.
You could try debugging this by commenting out parts of you code and trying to isolate which line(s) generate this error, then trying to rewrite the part you identified differently.
1 Like
Interesting… if this is not due to a timeout error when compiling it can very well be a bug in the shader compiler that you ran into. I’d report it in the SPRIV forums and see if you get any response there. Trying to isolate the exact line(s) that cause this problem and can reproduce it, and post them here and on their forums could be a great way forward. Maybe someone will be able to either help you find a workaround or try and fix the bug in the compilers themselves.