Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Shader keyword limit

Discussion in 'Shaders' started by LukasCh, Aug 15, 2018.

?

Which solution works best for you?

  1. 1

    60.6%
  2. 2

    4.3%
  3. 3

    35.1%
  1. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Hello folks!

    Recently we seen some users experiencing issues with limited keyword count. As result we decided it might be a could time to revisit this problem again.

    So for some who do not know about the global keywords limit, here is quick explanation.
    Basically when you declare any new keyword in shader (etc. multi_compile, shader_feature) or with scripting API (etc. Shader.EnableKeyword, Material.EnableKeyword...) we actually assign unique index from 0 to 255 and store it as global dictionary between the name and index. This allows us to store enabled keywords as bitmask, this way increasing all keyword related operations significantly. However as some of you already aware it restricts project from having more than 256 unique keywords across all the shader. Usually it is not that easy to hit the cap, but that is not the case once you start to rely on third party packages.

    For this reason we were thinking about possible solutions for this issue and we decided it would be great to get feedback from you guys.

    1) Increase keyword count to 1024. Well this is actually the simplest solution and we already did this multiple times before.
    Advantages - we do not break the old functionality.
    Disadvantage - this affects keyword related performance, but we seen regression only if project actually uses more keywords.

    2) Make keyword completely local. It means every shader can have 256 unique keywords. However functions that modify keywords globally (etc. Shader.EnableKeyword, CommandBuffer.EnableShaderKeyword), must be removed or changed to simulate old functionality by patching local map.
    Advantages - we keep shader variant API intact, we get completly get rid of global keywords.
    Disadvantage - functions that change keywords globally must be removed or has to get very heavy internal change (That might not work exactly same in all cases as it would be simulated with local keywords).

    3) Add local keywords as additional functionality on current system. So basically hybrid mode to support local and global keywords at the same time. Idea is to leave 192 keywords for global and 64 for local per shader.
    Advantages - we keep old functionality intact.
    Disadvantage - we have to introduce new shader API that would allow specifying which keywords as local.
    Current idea is to deprecate multi_compile/shader_feature and introduce new unified pragma generate_variants that would have some additional options.
    For example:
    #pragma multi_compile A B == #pragma generate_variants nostrip global A B == #pragma generate_variants nostrip A B

    #pragma shader_feature A B == #pragma generate_variants strip global A B == #pragma generate_variants A B

    #pragma generate_variants strip local A B

    #pragma generate_variants nostrip local A B


    We currently have option 3 implemented, but not publicly available. The option 2 still requires a bit investigation, because it would require fundamental changes of keyword system.
     
    vlery, Skunk-Software, no00ob and 3 others like this.
  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    9,195
    I suspect option 1 will be the option most people will choose, but I suspect that option will just lead to a post in a few years of "should we increase the keyword count to 2048?".

    Option 2 seems bonkers, global keywords are exceptionally useful.

    Option 3 feels like the best option, though obviously won't solve the problem for most people until assets get updated and people learn the new paradigm.
    Also, why wouldn't #pragma shader_feature AB == #pragma generate_variants strip local A B ? I'm not sure I've seen any assets that try and change shader feature keywords globally as, at least in my mind, I already treat them as "local" keywords. Granted this has the potentially to break old assets, but it's already so dangerous to try to change potentially stripped keywords I would assume most people change to using multi_compile after finding shader_feature didn't work in a standalone build, and most people don't know about ShaderVariantCollections still.



    Somehow I can still imagine a future where people ask for local and global 1024 keywords ... we'll ignore the multiple gigabyte of shader variants this option leads to, and that static branches are basically free on modern GPUs.
     
    Danebulus and P_Jong like this.
  3. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    @bgolus, thanks for respond and those who voted in poll.

    We come up with different approach for third option. What differs - global keyword limit will be left intact to 256 and we will add additional 64 for local and instead of introducing new user variant directive (etc. generate_variants, propose above), we will expose per shader in shader import settings if user wants to treat their shader_feature or/and multi_compile as local (Will be off by default).
    This solution will be much safer choice as it would not only leave old functionality intact, but at the same time will allow some users to use it and isolate it per shader.

    In the future we still thinking about new user variant directive that would encapsulate local/global/multi_compile/shader_feature functionality (As the naming for shader_feature and multi_compile was not ideal, especially when they both have very similar functionality), but we also want it to cover the unneeded variant striping (That is currently big issue of variant explosion)
     
    Danebulus, MaxProude, Fijit and 2 others like this.
  4. Duffer123

    Duffer123

    Joined:
    May 24, 2015
    Posts:
    1,091
    @LukasCh ,

    What ultimately happened with this?
     
  5. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    We decided to drop this idea, as it will break consistency with our shader compilation. For this reason we decided to introduce just varations of shader directives shader_feature_local and multi_compile_local.

    Currently local keywords landed in 2019.1 and will be available for alpha users. Here is more information about it https://docs.google.com/document/d/156MgqojKIgWgrpJLJ0WgD8pVzG0A0T42e3wr0d0oaLg/edit.
     
  6. Duffer123

    Duffer123

    Joined:
    May 24, 2015
    Posts:
    1,091
    @LukasCh ,
    Thanks for responding. I found a way to row back on the sheer number of shaders in my project in the meantime... ;)
     
  7. FarNiche

    FarNiche

    Joined:
    Jul 24, 2014
    Posts:
    8
    Where Do Those Shaders Come From?
    I've found that many people do many things in many different ways to get what they are trying to express to work as they intend. As a test I've loaded over 555GB of asset packages into one Unity project while working in 3D. Doing that, I have also reached the 256 shader definition limit and at times have no idea of who added what to my shader list. That project only runs in Play-Mode on a fast Solid State Drive not a Disk Drive. I've tested that also. Even so, I'm pulling for the Asset Store creators/contributors creativity. I would opt for a 1024 shader definition limit as the way to go but also a way to see whom added which shaders from where. Having that shader info documented by the contributor might be a Best Practice, but maybe a set of log files built from the Unity Game Engine itself could automate that procedure. Thanks for the post.
     
  8. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    2,557
    I am dead excited to try this out! Didnt realise they were going to be added so soon!
     
  9. nbd

    nbd

    Joined:
    Aug 18, 2014
    Posts:
    34
    why not make the keyword limit configurable while a good solution is implemented? That way we will at least get to test our projects quickly.
     
  10. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Could you elaborate? I'm guessing you mean changing global keyword limit between 1-256?

    If you mean just plainly increasing keyword count while local keywords are developed. Well the biggest reason is that by increasing keyword count will result in performance decrease (It is not much, but it is static increase that will never go away). Even after the local keywords, we could not reduce keyword count as most of the user would depend on it by now (Even now, I would say 256 of global keywords is way too much, if we would had local keywords by now).
     
    Last edited: Dec 21, 2018
  11. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Hello, another batch of changes related to local keywords landed in 2019.1.0a14.
    These includes:
    - Fix for subshaders not correctly working with local keywords
    - Fix for material properties copying
    - Other small fixes
    - Moved 38 of unity builtin keywords from global to local. In result unity now only occupies 38 global keywords by default instead of 79
    - Added new button in shader inspector to show what global and local keywords it uses
     
    P_Jong, Paul-Swanson, twobob and 2 others like this.
  12. MaxProude

    MaxProude

    Joined:
    Feb 24, 2013
    Posts:
    160
    Does this improve surface shader compilation time as well? I have a big shader with many shader variants, that I've tested independently to be working, but if they are all added into the shader it compiles until it fails. It seems like I have to always disable one feature no matter which one it is. The strange thing is that it doesn't tell me what the problem is, since the error message is very cryptic.
     
  13. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Well local keywords feature was not designed to shader compilation purposes, so it should no affect it in any way (If it is slower, it means it is a bug). Could you post the shader I would gladly look into it.
     
  14. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Oh I though it is related to local keywords, if it is really not - could you make new thread with this and poke me in there. I do not want to mix threads that would result only in confusion.
     
    P_Jong and MaxProude like this.
  15. MaxProude

    MaxProude

    Joined:
    Feb 24, 2013
    Posts:
    160
    Thanks! I've deleted the original post and moved it here.
     
  16. nbd

    nbd

    Joined:
    Aug 18, 2014
    Posts:
    34
    Sorry, been a while. I meant to make the keyword count a configurable property, perhaps in the project settings. The default value of the property would be 256. But the developers should be able to configure it to be anywhere between 0 to 1024 perhaps. the upper limit would be a hard limit with comments suggesting that its an interim solution and that it would be deprecated in favor of local keywords. Developers will have to go the way of local keywords to realize performance increases anyway(if they feel its significant). This will give developers some time to plan for localizing their keywords. I don't know if its doable, but I think it will make it easier for us. Thanks.
     
  17. nbd

    nbd

    Joined:
    Aug 18, 2014
    Posts:
    34
    @LucasCh,

    Any comments on the above? Thanks.
     
  18. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Oh okey I understand what you mean now, we had some idea before the local keywords. However there is few reason why we decided to drop it:
    1) In unity all keyword variations are packed from strings array into 256 bit size integer (This is where limits comes) and in global map strings are stored. For configurable keyword limit we would had two solutions:
    a) In every code part make this integer size configurable, with this we would lose performance from build time optimisations.
    b) in every code part up this integer to maximum limit (etc. 1024), so in the end we would have some behaviour as just simply increasing the maximum.
    2) I fear that users would set it always to maximum to avoid headache in future (Even though if we had default like 256). In the end it would be simply another increase of global keyword count.
    As you mentioned before, to use this feature as a transition to local keywords. I believe it could bring more harm as we might end up supporting two ways and reducing limit back to 256 would be impossible.
     
  19. nbd

    nbd

    Joined:
    Aug 18, 2014
    Posts:
    34
    No problem. Thanks for the info.
     
  20. GorkaChampion

    GorkaChampion

    Joined:
    Feb 6, 2018
    Posts:
    102
    So...Whats the solution to all of us that reached the 256 limit? Any update soon? We can't download more assets on the store and also I have to delete same of then because I get the error 256 limit very often, so basically it's quite hard to keep working in our project.

    On the other hand HDRP will have the same limit?

    Thanks
     
    Matro likes this.
  21. Matro

    Matro

    Joined:
    Mar 15, 2013
    Posts:
    38
    I ask the same question what do we do when we hit the 256 limits?
    I have not found anything on how to manage this other than the asset Shader Control, I am not opposed to buying another asset if that is the only solution but I can say that is kinda dumb if removing other assets that I don't need will solve it. I have many assets that I have bought but if I can strip out the parts I don't need it will be better overall for any project.
     
  22. Tyrant99

    Tyrant99

    Joined:
    Dec 6, 2018
    Posts:
    4
    If we were to use only the built in HDRP shaders in a project, it would look something like this:

    Keyword Count:
    Layered Lit = 108
    Lit = 86
    Terrain Lit = 56
    Lit Tessellation = 71
    Layered Lit Tessellation = 98
    Decal = 8
    Unlit = 29

    Total = 456

    It's hard to see how the 256 shader keyword cap will come anywhere close to meeting the needs of the new SRPs.

    Let me know if I'm misguided in my assessment.
     
    Last edited: Apr 5, 2019
    holyfot and P_Jong like this.
  23. Lynxed

    Lynxed

    Joined:
    Dec 9, 2012
    Posts:
    97
    Is this taken into account in ShaderGraph in 2019.1? I'm on 2018.3 and I have a very big shader (art direction request) , which is now stored in "Failed to complie", because of 256 keyword limit. Will moving to 2019.1 help?
     
  24. FiveFingerStudios

    FiveFingerStudios

    Joined:
    Apr 22, 2016
    Posts:
    404
    I rely on many 3rd party assets for my project. I recently added one more and noticed that one of my older shaders no longer compiles. Is this the case when you go over the keyword 256 limit?

    If so, how to I check all shaders for keywords in my project so I can remove the ones I don't need?

    Btw, I'm on Unity 2017.4.24f1
     
  25. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    1,053
    A lot of those are platform and feature dependent keywords that should be stripped on build, no?
    I'd imagine HDRP will also start to make use of this local keywords feature as time goes on too.
     
  26. 30035172

    30035172

    Joined:
    Jun 25, 2016
    Posts:
    4
    Please increase the limit....
     
    P_Jong likes this.
  27. AndreasO

    AndreasO

    Joined:
    Sep 25, 2012
    Posts:
    90
    Yes, we need more control over this. 256 is not enough.
     
  28. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    HDRP uses local keywords so that should be fine

    What version you are using? As HDRP uses local keywords and Lit shader actually only uses 20 global keywords (~6 of them builtin) and most of these keywords reused in all the shaders that you described.

    You can try local keywords, very simple way to try it just replace all shader_feature -> shader_feature_local in your project and restart unity. This should be safe any easy way to try them and see if it helps
     
    P_Jong likes this.
  29. Lynxed

    Lynxed

    Joined:
    Dec 9, 2012
    Posts:
    97
    Thanks! That company fired me like 3 months ago, but i'll give it a shot next time.
     
  30. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,510
    Hi @LukasCh,

    Could you please comment on the disadvantages of switching an existing shader global keywords declaration to local, if any?
    • How performance is impacted? Is it build performance or runtime performance?
    • Is the new system designed so we can simply switch all shader keywords to local in the entire project? (apart from Shader global API exceptions) Or will it break or have a great performance impact if there're lots of shaders using local keywords?
    • multi_compile vs shader_feature to local: are there any differences? Is it safe to switch shader_feature to shader_feature_local?
    Thanks.
     
    WildStyle69 likes this.
  31. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Hey @Thrawn75,

    You should find all the answers in this doc under the "Local Keywords" - https://docs.unity3d.com/Manual/SL-MultipleProgramVariants.html. If does not answer your questions fully, let me know I will try to elaborate it and it will be good indication for us to extend documentation on it.

    Sad to hear, I hope your next company will better :)
     
    Thrawn75 likes this.
  32. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,510
    Thanks for the prompt reply Lukas!

    Yes, I think the doc can be further improved IMO:

    I think you should remove the reference to the "plus 64 local keywords" part in this paragraph as it seems to suggest that the 64 local keywords is a shared limit whereas it's per shader and I understand shader_feature and multi_compile does not affect this 64 limit at all.

    I still have a question regarding performance. Is there any runtime performance impact by switching a keyword to local (either multi_compile or shader_feature)?
    Thanks!
     
  33. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Hey, thanks for feedback.
    Technically speaking, whole performance comes from how many keywords does individual shader has in total global+local. Lets say if project ends up moving some of its global keywords into the local, it would end up as performance increase, because this way individual shader would have less keywords in total.
    I can not provide any exact numbers or procents in this case as the feature was never designed for performance and more as solution for keyword count problem. By all no means, you should not see any regression in performance by using local keywords for sure.
     
    Thrawn75 likes this.
  34. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,510
    Good news then :)
    I've added a new option to our Shader Control tool to locate and convert shader feature keywords to local with a click which should help reducing the max global keyword count issue.
     
    FeastSC2, WildStyle69 and LukasCh like this.
  35. rmon222

    rmon222

    Joined:
    Oct 24, 2018
    Posts:
    69
    @Thrawn75 I just bought shader control and did not find enough keywords to delete to go under the 256 limit. Is that new option to convert feature keywords to local in the current asset at the asset store? or can I have a patch in advance? This keyword limit is stifling new features.
     
  36. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,510
    Hi, thanks for trying Shader Control. I'll send you a pm with details.
    Regards
     
  37. DropNodes

    DropNodes

    Joined:
    Jun 11, 2019
    Posts:
    39
    Bought shader control for the same reason, could you please let me know too as to how to go under 256 with the new feature?
     
  38. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    2,510
    @LukasCh According to the documentation:

    "There is a maximum of 64 unique local keywords per shader".

    This seems to be false and it's per project instead - could you please check this issue? Just create two shaders and declare 64 unique keywords in one and a few others in the other. You will see the limit exceeded warning in the console. I submitted a repro (case 1191820).

    EDIT: ends being a temporary issue - Unity seems to keep removed keywords in a cache until it's restarted.
     
    Last edited: Oct 17, 2019
  39. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    Hey, I tried the project you assigned with 2019.2.9f1_ebce4d76e6e8/trunk win/mac, but I could not reproduce it. I checked the log you assigned, so I noticed there is some errors with exceeding local keywords, but at the same time I noticed more keywords/resources and different shaders in it.
    My guess you stripped something in repro project that was causing it, could you re-check repro project.
    Also lets move conversation into fogbugz, so we would avoid flooding this thread.
     
  40. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    Dont understand the docs. You mention "multi_compile is better for keywords that are set from code globally" but there is also the option "multi_compile_local"
    Also mention "The process for enabling local keywords is the same as enabling global keywords" but that is not the case as global is set using Shader.EnableKeyword and local is set with material.EnableKeyword
    Dont know what is the proccess to make local the global shaders, we must know what materials use that global shader and change the scripts to set each material to enable the keyword for multi and shader feature?
    And what is the point of using multi if shader feature doesnt include in build the shaders not used?
    In my project i am getting also the error for keywords that doesnt even exist in the project, for instance Maximum number (256) of shader global keywords exceeded, keyword _WINDVERTEXCOLORMAINR_ON will be ignored. . Searched the whole project for _WINDVERTEXCOLORMAINR_ON and doesnt exist
    Tried using Shader control in the asset store but doesnt solve this issue either, after changing all shaders from global to local i still get the errors, but are shaders using multi. I have read shader feature keeps the keywords in the materials though dont know what that exactly means, as i checked materials with shaders using shader feature local and i cannot set any keyword in the material in the inspector so where those keywords are enabled??
     
  41. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    Also includes #pragma shader_feature_local BAKERY_SHNONLINEAR as global keyword, dont understand anything, tells me "Maximum number (256) of shader global keywords exceeded, keyword BAKERY_SHNONLINEAR will be ignored."

    EDIT : i see there is also that keyword as global #pragma shader_feature BAKERY_SHNONLINEAR
     
  42. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    Also what gives better performance more local keyword or global keywords? And why this matters in performance?
     
  43. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    What is the diffference of shader feature local and global? i see shaders with global just using toggle to set it or not in the material but the same can be done with local
     
  44. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    You should control the quality of the assets in the asset store and force to set shaders as local
     
  45. NewMagic-Studio

    NewMagic-Studio

    Joined:
    Feb 25, 2015
    Posts:
    205
    Changed all the shaders of my project from shader_feature to shader_feature_local and i still get the same errors, dont know why sometimes gives me different number of errors mentioning the max 256 error
     
  46. LukasCh

    LukasCh

    Unity Technologies

    Joined:
    Mar 9, 2015
    Posts:
    84
    You are partly correct.
    Shader.EnableKeyword is for global.
    material.EnableKeyword is for global and local. It depends from shader that is assigned to material, if local keyword exists with that name it will enable it as local if not it will be enabled as global.
    The reason it works that way, as we wanted to make transsition to local keywords as fluent as possible, basically it works same as pre local keywords.
    There should be a warrning if shader contains keyword with same name for local and global.

    You can find this info in https://docs.unity3d.com/Manual/SL-MultipleProgramVariants.html.
    "You might see a change in performance when you start using local keywords, but the difference depends on how your Project is set up. The total number of local and global keywords per shader affects performance: in an ideal set-up, use more local keywords and fewer global keywords, to reduce the total keyword count per shader." (If that does not makes sense, I can eleborate a bit more"

    Did you tried re-opening project, as global keyword are not cleaned until unity is restarted (That is limitation from out side and how it works).
     
    Fibonaccov likes this.
  47. BradZoob

    BradZoob

    Joined:
    Feb 12, 2014
    Posts:
    46
    Is it possible for us to compile our own version of Unity so this nightmare of a problem just goes away?
     
  48. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    1,466
    I upgraded my project from 2019.2, HDRP 6.9 to 2019.3.3f1, HDRP 7.1.2 and am now in this hellish nightmare with no idea what to do because the error message is saying words, but no content:

    Code (CSharp):
    1. Maximum number (256) of shader global keywords exceeded, keyword MATERIAL_QUALITY_LOW will be ignored.
    2. You will have to delete some shaders or make them use less keywords.
    3. Keywords used in project now: AT_HUE_VARIATION_OFF AT_HUE_VARIATION_ON BILLBOARD_FACE_CAMERA_POS BLIT_SINGLE_SLICE DEBUG_DISPLAY DECALS_3RT DECALS_4RT DECALS_OFF DIFFUSE_LIGHTING_ONLY DIRECTIONAL DIRECTIONAL_COOKIE DIRLIGHTMAP_COMBINED DIRLIGHTMAP_OFF DIRLIGHTMAP_SEPARATE DISABLE_TEXTURE2D_X_ARRAY DYNAMICLIGHTMAP_OFF DYNAMICLIGHTMAP_ON EDITOR_VISUALIZATION EFFECT_BILLBOARD EFFECT_BUMP EFFECT_EXTRA_TEX EFFECT_HUE_VARIATION EFFECT_SUBSURFACE ENVIRO_CURLNOISE ENVIRO_DEPTHBLENDING ENVIRO_HALTONOFFSET ETC1_EXTERNAL_ALPHA FAR_CULL_ON FAST_SIN_ON FOG_EXP FOG_EXP2 FOG_LINEAR GEOM_TYPE_BRANCH GEOM_TYPE_BRANCH_BLEND GEOM_TYPE_BRANCH_DETAIL GEOM_TYPE_FROND GEOM_TYPE_LEAF GEOM_TYPE_MESH GPU_FRUSTUM_ON HDRP_ENABLED INSTANCING_ON IS_DRAWPROCEDURALINDIRECT LIGHTMAP_OFF LIGHTMAP_ON LIGHTMAP_SHADOW_MIXING LIGHTPROBE_SH LIGHT_LAYERS LOCAL_SPACE LOD_FADE_CROSSFADE LOD_FADE_PERCENTAGE LWRP_ENABLED MULTI_BOUNCE_INDIRECT OUTPUT_SPLIT_LIGHTING PIXELSNAP_ON POINT POINT_COOKIE PROCEDURAL_INSTANCING_ON SHADOWS_CUBE SHADOWS_DEPTH SHADOWS_SCREEN SHADOWS_SHADOWMASK SHADOWS_SINGLE_CASCADE SHADOWS_SOFT SHADOWS_SPLIT_SPHERES SHADOW_HIGH SHADOW_LOW SHADOW_MEDIUM SHADOW_VERY_HIGH SHOW_FEATURE_VARIANTS SHOW_LIGHT_CATEGORIES SOFTPARTICLES_ON SPOT STEREO_CUBEMAP_RENDER_ON STEREO_INSTANCING_ON STEREO_MULTIVIEW_ON TOUCH_BEND_ON TRANSPARENT_COLOR_SHADOW UNITY_COLORSPACE_GAMMA UNITY_HDR_ON UNITY_PASS_SHADOWCASTER UNITY_SINGLE_PASS_STEREO UNITY_UI_ALPHACLIP UNITY_UI_CLIP_RECT USE_CLUSTERED_LIGHTLIST USE_FPTL_LIGHTLIST USE_HDWIND USE_MIS USE_NOISE_TEXTURE USE_SNOW UseFlowMapping VARIANT0 VARIANT1 VARIANT10 VARIANT11 VARIANT12 VARIANT13 VARIANT14 VARIANT15 VARIANT16 VARIANT17 VARIANT18 VARIANT19 VARIANT2 VARIANT20 VARIANT21 VARIANT22 VARIANT23 VARIANT24 VARIANT25 VARIANT26 VARIANT27 VARIANT28 VARIANT3 VARIANT4 VARIANT5 VARIANT6 VARIANT7 VARIANT8 VARIANT9 VERTEXLIGHT_ON WATER_REFLECTIVE WATER_REFRACTIVE WATER_SIMPLE WIND_DISTANCE_CULL_ON WORLD_SPACE WRITE_MSAA_DEPTH WRITE_NORMAL_BUFFER _ADDITIONAL_LIGHTS _ADDITIONAL_LIGHTS_VERTEX _ADDITIONAL_LIGHT_SHADOWS _ALBEDOCONTRIBUTION _ALPHABLEND_ON _ALPHAPREMULTIPLY_ON _ALPHATEST_ON _ANIMATEDMELT_ON _BENTNORMALMAP0 _BENTNORMALMAP1 _BENTNORMALMAP2 _BENTNORMALMAP3 _COLORMAP _COVERAGEFADE_ON _CROSSROADUSEUV4_ON _CROSSROADUV3_ON _DEBUG_MASK_ON _DETAIL_MAP0 _DETAIL_MAP1 _DETAIL_MAP2 _DETAIL_MAP3 _DETAIL_MULX2 _DETALUSEUV3_ON _DISABLE_DBUFFER _DISPLACEMENT_LOCK_TILING_SCALE _DISTANCEBLEND_ON _DOUBLESIDED_ON _DYNAMICFLOWS _EMISSION _EMISSIVE_COLOR_MAP _ENABLEFOG_ON _ENABLEROTATION_ON _ENABLESPECULAROCCLUSION _GLOSSYREFLECTIONS_OFF _HEATMAP _HEIGHTMAP0 _HEIGHTMAP1 _HEIGHTMAP2 _HEIGHTMAP3 _HEIGHT_BASED_BLEND _IGNORECROSSROADALPHA_ON _IGNORESECONDROADALPHA_ON _INTERPOLATE_LAYERS_ON _INVERTVCOLORMASKSECONDROAD_ON _KEYWORD0_ON _LAVA _LIGHTMAPPING_DYNAMIC_LIGHTMAPS _LIGHTMAPPING_REALTIME _LIGHTMAPPING_STATIC_LIGHTMAPS _LOWPOLY_ON _MAINROADUV3_ON _MAIN_LIGHT_SHADOWS _MAIN_LIGHT_SHADOWS_CASCADE _MASKMAP _MASKMAP0 _MASKMAP1 _MASKMAP2 _MASKMAP3 _MATERIAL_FEATURE_CLEAR_COAT _MATERIAL_FEATURE_SUBSURFACE_SCATTERING _MATERIAL_FEATURE_TRANSMISSION _MAX4TEXTURES _METALLICGLOSSMAP _METALLICSPECGLOSSMAP _MICROSPLAT _MIXED_LIGHTING_SUBTRACTIVE _MSRENDERLOOP_SURFACESHADER _NORMALMAP _NORMALMAP0 _NORMALMAP1 _NORMALMAP2 _NORMALMAP3 _NORMALMAP_TANGENT_SPACE _NORMALMAP_TANGENT_SPACE0 _NORMALMAP_TANGENT_SPACE1 _NORMALMAP_TANGENT_SPACE2 _NORMALMAP_TANGENT_SPACE3 _OCCLUSIONMAP _PARALLAX _PARALLAXMAP _PERTEXUVSCALEOFFSET _PUDDLES _RAINDROPS _REQUIRE_UV3 _SECONDROADUV3_ON _SHADOWS_SOFT _SMOOTHNESS_TEXTURE_ALBEDO_CHANNEL_A _SPECGLOSSMAP _SPECULARHIGHLIGHTS_OFF _SPECULAR_OCCLUSION_FROM_BENT_NORMAL_MAP _SPECULAR_OCCLUSION_NONE _SPLATMAP_PREVIEW _STATICHIGHLIGHTS_ON _SUBSURFACE_MASK_MAP0 _SUBSURFACE_MASK_MAP1 _SUBSURFACE_MASK_MAP2 _SUBSURFACE_MASK_MAP3 _SURFACE_TYPE_TRANSPARENT _TERRAINBLENDING _TERRAIN_INSTANCED_PERPIXEL_NORMAL _TERRAIN_NORMAL_MAP _TESSDISTANCE _TESSELLATION_PHONG _THICKNESSMAP _THICKNESSMAP0 _THICKNESSMAP1 _THICKNESSMAP2 _THICKNESSMAP3 _TOGGLEANIMATEDFX_ON _TOGGLEBLUR_ON _TOGGLECONTROLTYPE_ON _TOGGLESWITCH0_ON _TOUCHREACTACTIVE_ON _USEDYNAMICCOVERTSTATICMASKF_ON _USEDYNAMICSNOWTSTATICMASKF_ON _USEFLOWMAPPING_ON _USEGRABSCREENCOLOR_ON _USEGRADMIP _USESECONDROADALPHA_ON _USESNOWHEIGHTMAPFORBLEND_ON _USESNOW_ON _UVSEC_UV1 _WINDCOLORMIX_ON _WINDQUALITY_BEST _WINDQUALITY_BETTER _WINDQUALITY_FAST _WINDQUALITY_FASTEST _WINDQUALITY_NONE _WINDQUALITY_PALM
    4. UnityEngine.Rendering.CommandBuffer:DisableShaderKeyword(String)
    5. Utilities.MaterialQualityUtilities:SetGlobalShaderKeywords(MaterialQuality, CommandBuffer) (at Library/PackageCache/com.unity.render-pipelines.core@7.2.1/Runtime/Utilities/MaterialQuality.cs:139)
    6. UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)
    7.  
    I mean what is this:

    Code (CSharp):
    1. VARIANT0 VARIANT1 VARIANT10 VARIANT11 VARIANT12 VARIANT13 VARIANT14 VARIANT15 VARIANT16 VARIANT17 VARIANT18 VARIANT19 VARIANT2 VARIANT20 VARIANT21 VARIANT22 VARIANT23 VARIANT24 VARIANT25 VARIANT26 VARIANT27 VARIANT28 VARIANT3 VARIANT4 VARIANT5 VARIANT6 VARIANT7 VARIANT8 VARIANT9
    And this:

    Code (CSharp):
    1. You will have to delete some shaders or make them use less keywords.
    How should I know what to delete? I'm importing assets from the store and using Unity. No idea where those keywords are stored. I've seen there are paid assets which show you which keywords aren't used, but why would I have to buy expensive assets to fix Unity?
     
    daisySa, ftejada and sunseeker1988 like this.
  49. sunseeker1988

    sunseeker1988

    Joined:
    Jul 10, 2014
    Posts:
    453
    I'm having this issue and its complete hell. Ive replaced ALL shader_feature_local and multi_compile_local, deleted 90% of all my shaders and I'm still getting this freaking error. unitys solutions are NOT helpfull to a large majority of us who still cannot figure out why the hell we are having this issue. i have a 6 year project DEAD IN THE WATER because of this. i have purchased asset finding solutions and spent DAYS trying to figure this out. Unity needs to make this a HELL of a lot easier for developers to deal with. I need to see EASILY where the last 10 percent of shaders I have in my project have used up all available shader keywords even though I went through EVERY shader and renamed all shader_feature and multi_compile to include _local and still no freaking cigar. is it possible stuff is getting cached somewhere even after restarting unity? would be nice to see USED shaders in my project and what keywords they are using and an option that can fix whatever god forsaken issue with global, local whatever needs to be fixed.

    Unity says this is not an issue with new HDRP shaders but I ONLY received these MASSIVE MASSIVE MASSIVE amount , hundreds of global shader keyword errors in the compiler only after upgrading from 2018.3 to unity 2019.3 and implemented the new HDRP pipeline and converted all materials to HDRP.
     
  50. sunseeker1988

    sunseeker1988

    Joined:
    Jul 10, 2014
    Posts:
    453
    Still an issue. I have deleted ALL SHADERS from my project and I still have a THOUSAND FING GLOBAL KEYWORDS! my project is toast, Unity 2019.3 is broke as hell and the HDRP pipeline is a nightmare. I hope unity figures out how to fix this because it will wreck a project real fast. I am seeing global keywords for assets I have deleted entire folders no shaders but the global keywords are still in the project, showing up under the massive amount of compile errors as "keywords currently used in this project". I am talking about hundreds of keywords from many assets that no longer exist in the project. I have restarted unity about 100 times, no avail.
     
    Last edited: Mar 17, 2020
unityunity