WARNING: Shader Unsupported: ‘shadername’ - All passes removed
This warning started showing up very recently on a project on a LARGE amount of shaders, including the default HDRP/Lit.
Can anyone shine some light - Is it serious, is there anything I should do to avoid it or make it go away?
If “all passes” of a shader were really removed, wouldn’t it stop drawing all together?
Thank you!
YEah, got the same warnings and dont know how to get rid of them 
Listen…HDRP uses its own default shaders, which you have to comply with. This means you have to convert to the HDRP shaders on all your materials, as custom shaders that are non compliant, are not supported, wont work.
But these messages also occur for the default, unmodified HDRP/Lit and HDRP/Unlit shaders…
Hi,
we indeed get this message sometime on our own hdrp shader, we still have to find the root cause of why this is emit, but it is harmless.
Hi, we have found the cause of the issue and will solve it
Could you please share some way to track this issue?
getting this on builds in 2019.3.14f1
getting this on builds in 2019.4.0f1
getting this on 2019.4.0f1 linux builds with Vulkan, but not on windows builds.
@SebLagarde , can you confirm whether this is A) Fixed, and/or B) Actually harmless? I’m getting this warning in my build only recently, sometime after going from 7.3.1 to 7.4.1, I believe, but accompanied by this error immediately at startup:
This error is thrown by CoreUtils.cs in its `CreateEngineMaterial(Shader shader)’ method. I’ve tried recreating all HDRP resources and updating all materials to use the latest HDRP materials to the latest version, via the HDRP Wizard, but I still get this when I build. Since CreateEngineMaterial doesn’t take any other parameters other than the null shader, I’m having a hard time tracking down what it’s looking for.
Hi,
So to clarify:
I confirm this is harmless, this warning is show only because we have a sub shader Raytracing that is not used on DX11. The “fix” is currently just to not show this warning 
“Fix” will not be backport on 19.3 (at least as far as I can tell as it doesn’t fix anything). And is not in any public binary currently. We are still working on it, as there is some rare cases where this warning make sense and we shouldn’t remove the message fully.
In my case, it is very much harmful as the object just renders as black. The shader of that object returns this error:
WARNING: Shader
Did you use #pragma only_renderers and omit this platform?```
For the record, I am using Unity 2019.4.0f1 and building for WebGL (WebXR use case).any luck with this? I seem to be getting build crashes from these errors…
n my case, it is very much harmful as the object just renders as black. The shader of that object returns this error:
Note, here we talk only about HDRP. HDRP don’t support WebGL.
any luck with this? I seem to be getting build crashes from these errors…
Those warning can 't crash your projects, they are just warning in console. The fix that landed in 2020.2 and soon will land in 2020.1 simply don’t display it.
Important: If you have an issue when you build HDRP and you see this message: “unsupported shader warning” there is 99% chance it is not related at all to it.
Here’s a crash report if this helps, I’m dead in the water over here…not sure what happen but I cant build anything anymore…
I have this issue. Everything works fine in editor. When I build the game, my grass is not drawn and I have the warning pointing out the related shader in the log. Using 2019.4.1… Will try with 2020.1, and I hope that works. Otherwise, this means migrating to HDRP during the last 3 months was a mistake since unity does not provide a production ready (or approved) product (even though they claim they do so)… Very serious trust problems right now… As I say, I hope there is a fix for this, either by upgrading the editor, or modifying the related shader by myself.
Hey, I tried repro your issues, building a player (19.4 and HDRP 7.4.1) with a small terrain with both supported and unsupported shader in the scene, nothing unexpected happened (whether with a development build or not). Could not repro a crash.
@SinDeSiecle , what are you using for your grass ? As far as I know, details shaders (for grass and vegetations) are not supported by HDRP
@darkAbacus247 , It would help us a lot to have a repro project for us to investigate on your crash. Can you send something like that ?
I’d be happy to, I can upload tonight once home.
After a bit of research some users are pointing to hardware being the issue, so currently attempting to build via an old rock I had in the closet…if it works then I suppose I am a bit closer to knowing whats up. Though it takes the older computer roughly 6 millennia to do the same work.
Either way, Yeah I’ll upload report later tonight…
Thanks for looking into this for me! Truly appreciated
BTW, should I just follow unity’s standard report process, or do you have a preferred method of contact?
@chap-unity , I just tried a build with 2020.1, the problem persists. My setup differs from conventional terrain based setup. Simply, creating a part of a large planet surface by many bending many plains and replacing the vertices according to the height map values and by the distance from the center of the planet. Foliage and rocks are placed on top of this surface. Which has no importance on our problem, but i am mentioning these for the safe of explanation of what i have just said. For foliage and rocks, i use the GPUInstancer asset on asset store. Interesting thing is, 2 grass prefabs and 1 rock prefab is not drawn on the build. But, other rock and plant prefabs on the same asset setup are drawn. The grass prefabs has a specific shader by the asset. But the other not rendered rock has hdrp lit shader. Again, in the logs for the build, i have the warning we are talking about pointing out the GPUInstancer/foliage shader. But, right after that, Another version of that warning is pointing out a HDRP Lit shader. I did not want to contact the developer before trying upgrading to 2020.1 and see if it makes a difference. Also there is this suggestion Reddit - Dive into anything suggesting to modify Managed Stripping Level. Next step is to try that. So, I will zip the project folder, first, which will take a few hours, because sometimes if I open the player settings window, all my lights (including directional lights) are gone in entire project. I wrote to another thread for this light problem.
Also, I have the max shader keywords exceeded warning active in the project. I first tried to relate this problem to that. but, the same shader working for 1 rock and 1 plant prefab, but not working for 2 grass prefabs and 1 rock prefab does not make sense in that case. If that was the problem causing this, none of my prefabs should have been drawn on the screen. A mid-step before contacting developer may also be to verify the problem is not the max keywords problem.
So, this is as far as I can think to solve the problem. Even, I could not diagnose the problem, so far, and I am literally blind. Well,I will try. I had so many similar processes with HDRP that I am considering to unzip the built-in render pipeline version of the project, and re-do all of the advancement I have achieved since I migrated to HDRP (implementing all of the sounds, all of the additional addressables since that zip was made, all of the new scripts that changed the entire mechanism of the game). And, yes, I assure you I did lots of tests with HDRP before deciding to migrate and make all of those advancements on top of that. Now, I am just sad. I just did not foresee that shader might not work, everything was (and is) ok besides that.
Anyway, thank you for your time you spared on my problem, I really appreciate. Any diagnostic suggestions would help, at least your opinion on max keywords exceed hypothesis of mine as the source of this problem. If you say “no it can not be the source” then I have one less thing to test, and saves me sometime. Now, I will change the prefab shader to HDRP Lit and see if the prefabs are drawn on the build. If they are rendered, then I will contact to developer. If they are not rendered… Well, we’ll see…