I’m continuing to have all kinds of issues with GLCore on Mac. I’ve brought this up in the past regarding conditionals/loops not being compiled correctly under GLCore (while they work fine in GL legacy).
Today I implemented a Filmic Tonemapping post effect and have yet again run into GLCore issues. This time I get a black screen, while GL Legacy works fine.
If you’d like to try the code for yourself, I’ve pushed it to GitHub:
GLCore on Mac is definitely broken. Flickering, image distortion, missing textures… But it doesn’t happen on every hw configuration based on our experience. Integrated GFX works better then dedicated one for some reason. And newer versions of Unity have bigger problems. Our game looks ok on 5.3.0 and is a mess on 5.3.3.
There are some fixes in 5.3.3.p3 based on this beta forum thread. Didn’t try it though.
black screen on windows also… (tried on 5.4b10, 5.3.4f1, with all kind different settings…)
I found the root of the problem. GLCore/DX doesn’t like non-static global consts. I couldn’t find any mention of this in the docs and Unity gives no errors/warnings, but by simply adding static to each of the global tone mapping consts - the shader now works on GLCore/DX. I’ve updated the repo.
Would love to know from Unity if this is a bug or as intended?
Shame I didn’t take a look at the code. I could have warned you. I don’t know how exactly this translates to GLSL, but in HLSL every global variable is const by default. So, Unity will find it just like every other global variable and its value will be set from the material. That means it is likely zero in your case.
On the other hand, global static variable isn’t visible to the application. That is what you want. That is how you declare traditional constant in HLSL.
Wow. This is incredibly useful to know, thanks! It makes sense to a degree, but isn’t exactly intuitive and this is the first I’ve heard of this behavior. Global consts just being interpreted as uniforms seems like something that should be advertised in giant neon letters! Pretty sure this is the reason for some long standing bugs I’ve had in other shaders too.
Thanks again!
Yeah, I know what you mean. I made the same mistake myself in the past and helped bunch of people with it ever since. It is quite popular…
I don’t know what is your take on Microsoft but they always have a very good documentation and HLSL is no exception. You can read about const and static here.
Thanks for the link. I’ve become so used to Unity showing errors/warnings about differences between GLSL and HLSL compilation that I falsely assumed that would be the case here. In my opinion, considering the fact that HLSL global consts evidently can not be assigned to, the compiler should be able to consider that an error on the user’s part and give a warning.
Regardless, this was a good reminder to go straight to the source (i.e. HLSL language docs) when things seem ‘odd’.
Thanks again, super useful bit of info.
Well, you can initialize global const during variable declaration. That is legal. Just like you did it in your shader. You only can’t change its value afterwards. The problem is that Unity will overwrite this value with the one in material. That’s what Unity should warn you about. Ideally, Unity would read default uniform values when they initialize materials but they obviously don’t do that.
Anyway, happy I could help.