filament
filament copied to clipboard
google
WebGL build: shader compilation for builtin material gives syntax error
This is a weird one. Using the WebGL version and a very basic material, Chrome and Firefox both throw the following error when compiling the shader source:
WebGL: INVALID_VALUE: shaderSource: string not ASCII
COMPILE ERROR:
ERROR: 1:1: '' : syntax error
1: #version 300 es
2:
3: #define TARGET_MOBILE
4: #extension GL_GOOGLE_cpp_style_line_directive: enable
...
and the rest of the shader follows. After that, filament ends with
OpenGL error 0x501 (GL_INVALID_VALUE) in "void filament::OpenGLDriver::createProgramR(Handle<filament::backend::HwProgram>, filament::backend::Program &&)" at line 541
and of course after that everything else fails too.
Any idea? Filament 1.8.0. I don't have a minimal case but could try to make one if the above rings no bells.
matc -p mobile -o out.inc in.mat
with matc from a linux build of 1.8.0. Included as header into my C++ source (I'm driving filament directly from C++ code compiled by emscripten, not via the filament-js wrappers; the exact same code works on linux).
My gut feeling was that the 'string not ASCII' error was caused by some problem with inclusion of that header (maybe setting the size one too large so it includes a garbage byte at the end), but I can't see any such problem (and moreover none of this code was touched recently).
One further data point: if I stick some output into OpenGLProgram::OpenGLProgram(...) I can see that this fails already on the first shader it tries to compile, which identifies itself as programBuilder.getName()=="Skybox". So it's not my materials, nor my method of including them into my source.
The samples indeed work, though I had to downgrade emsdk from 1.39.19 to the 1.39.15 which you use. That may be a separate issue.
Will dig further.
Thank you @kpeeters. Could you try if you can to print out the first couple of characters fed to OpenGLProgram::OpenGLProgram as hexadecimal? This would give us an idea of what's going on.
I assume you mean the first few characters of shadersSource[i]? The first line until the first 0x0a reads #version 300 es. All characters in the shader source string satisfy isprint(x)==true || x==10, so the string not ASCII message (which only appears on firefox, not chrome) is weird...
Tracking invocation of OpenGLProgram::OpenGLProgram, I first get 8 cases in which programBuilder.getName()=="Filament Default Material", which are all successful. The next one has this set to Skybox and that's when the first error happens. After that I get a few of my materials, which all compile successfully. The first failure after this is on colorGrading, followed by fxaa and blit.
Does this only happen with Filament 1.8.0? Can you try with 1.7.0? I know we've seen this type of error message before, I'm wondering if it's caused by a change in our shaders.
@bejado With 1.7.0 the OpenGL shader compilation in OpenGLProgram::OpenGLProgram gives an error on the DepthOfFieldBlur shader, with
ERROR: 0:304: 'fragColor': must explicitly specify all locations when using multiple fragment outputs
which is what I reported in https://github.com/google/filament/issues/2546 and was somehow able to avoid eventually (though I can't reproduce anymore how, will need to step back through my commit history). So it's a different error there, most likely completely unrelated.
It is still a mystery to me how it can be that the filament webgl samples work fine, but my code does not, yet the shaders for which the problems arise are for materials which are filament built-ins. This sounds like I am missing a compiler/build flag, or not doing all Filament initialisation steps correctly.
But TL;DR: 1.7.0 does not seem to have the problem reported here.
Interesting, I'm able to repro this error by making a debug build for web. (which I almost never do, I always use release)
See validateCharacter here
https://chromium.googlesource.com/chromium/blink/+/refs/heads/master/Source/modules/webgl/WebGLRenderingContextBase.cpp#237
The culprit (in my case, at least) is the quotation marks in our #line annotations. 🤦
Yes Firefox has the same issue. We also recently learned that some mobile GPU's are similar to Chrome in that they perform character validation too early (see #2860)
If you use a release build, do you still see this issue? I'll let @bejado decide what to do (if anything) about this issue. One idea is adding a matc arg that disables line directives.
My recommendation now is to generate materials at runtime (not with matc) using the filamat-lite library, which removes the Google-style line directives that are causing the issue (see https://github.com/google/filament/pull/2860). In the future I could see possibly adding a flag to matc to do something similar.
Note that we do not yet have filamat binding for Web. However I think this isn't an urgent issue, since it can be avoided by simply using a release build for WebGL.