Search Unity

[Official] Feedback wanted: changing compiled shader format

Discussion in 'Shaders' started by Aras, Aug 25, 2014.

  1. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    So right now "compiled shaders" in Unity have this funky format, that looks like this: https://gist.github.com/aras-p/4b198ffbd627454284d6 (a source shader like this: https://gist.github.com/aras-p/eab8157b41facf4543d9 is compiled into it).

    We're thinking about possibly changing that format. For majority of you, this should be invisible.

    However, some might run into problems. Specifically:
    • If you ship "already compiled" versions of shaders to Asset Store, they would stop working.
    • If you use any shaders that are "already compiled" from the asset store, they would stop working.
      • In both of the above cases, shipping "precompiled" shaders is kind of mean, since that means they will not work on any future platforms, or any platforms you did not precompile them to. For example, if you ship a shader precompiled for DX+DX11+OpenGL, then it will not work at all on any console, mobile, or future platforms (DX12, GL4, ...).
    • If you're using Unity's shader compiler tools to produce "already compiled" versions and then load the resulting text at runtime using "new Material(string)", that would stop working.

    As to "why we would be doing it"; the reasons are:
    • Parsing & loading shaders from a text-based format at runtime is stupid. All shader data at runtime should be just binary.
    • Likewise, shipping compiled shaders in assembly (for d3d9) or pseudo-hex (d3d11, consoles) formats is stupid. All that data should be just binary.
    Would the above plan be problematic?

    Clarification: some way of seeing compiled shader result (assembly, instruction counts etc.) will of course stay in the editor. But the plan is to make the runtime shader data format much less readable.
     
    Last edited: Aug 25, 2014
  2. [RV]CWolf

    [RV]CWolf

    Joined:
    Jan 24, 2013
    Posts:
    33
    Personally, I would have no problem with this change.

    Ideally we would love to see API support for loading binary shaders at runtime from the file system (or by another method) though if this change was made.

    EDIT: The reason we would like to load shaders at runtime is for extensive game mod support. Ideally we'd like to allow advanced modders to create their own shaders and load them in as part of a mod.
     
    Last edited: Aug 25, 2014
  3. DanTreble

    DanTreble

    Joined:
    Aug 31, 2010
    Posts:
    590
    Change it! The "compiled shaders" format is a last resort for us, we have managed to mostly avoid it.
     
  4. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    I'm all for it.

    However, what would this mean for error reporting/debugging? I know it's improved from what it was, but sometimes it's handy to be able to open the compiled shader. Will #pragma debug still give us a decent enough insight into the fully created shader if we opened the compiled version?
     
  5. Acegikmo

    Acegikmo

    Joined:
    Jun 23, 2011
    Posts:
    1,294
    I'm not entirely sure why you would want to try and port/sell compiled shaders, as you might as well just port/sell the source, so it seems like an improvement in any case :)

    Personally though, I'm reading the compiled shaders to find out various metadata in Shader Forge. (Compiled paths and their pass instruction counts)

    If possible, it would be nice if Unity could add that data either into some header, or using some tools to extract that data (which could also be used by a shader inspector to give you some data on what's going on)
     
  6. Tigran

    Tigran

    Joined:
    Feb 20, 2013
    Posts:
    4
    In a Unite talk, you guys mentioned compiling surface shaders, then taking the compiled shader and modifying it as an easy way to create custom shaders with lighting. For example, if you don't need light probes, you can just remove that part from the generated shader.
    I haven't used this myself yet, but it does seem potentially very useful in the future. I understand this won't be possible anymore?
     
  7. guycalledfrank

    guycalledfrank

    Joined:
    May 13, 2013
    Posts:
    1,671
    Reading compiled shaders is very useful for debugging. But, of course, there is no reason to store anything non-binary in final build.
     
  8. MattCarr

    MattCarr

    Joined:
    Jul 5, 2009
    Posts:
    339
    I personally have no attachment to the compiled shaders. In fact I just spent 30 minutes re-writing the Candela SSRR shader from the OpenGL compiled source (since compiled DX9 and DX11 are as they are) so I could modify it for use in the Unity 5 beta with the new G-Buffers, so at this moment in particular the idea of not having that be a thing in the future sounds good to me.

    That said, as people have stated above, there is some benefit to being able to see the final compiled code for surface shaders. If there was a way of keeping it as an option to view them in a similar compiled state, but also remove or limit the ability for compiled shader source to be put on the Asset Store, which I think is a silly practice for a variety of reasons, then that might be ideal IMO.

    P.S. It turned out I didn't really need to modify the main obfuscated and compiled Candela shader. Mainly just the non-obfuscated, non-compiled blur and compose shaders needed to be modified for the new normal/spec/roughness buffers which took about 2 mins... :(. Such is life.
     
  9. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Sure, some way of "looking at compiled stuff" is a must in the editor, for shader authors (looking at assembly, instruction counts etc.). But shipping & loading the same format in the game? Not much.

    Starting with Unity 4.5 it's much easier. When you have a surface shader, press "show generated code" in the shader inspector, and you'll get the code that you can edit. However, that is not "compiled code" (assembly/bytecode), so not quite relevant to this topic.
     
  10. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,521
    Sure, go for it.
     
  11. jemast

    jemast

    Joined:
    Dec 7, 2011
    Posts:
    141
    Do it. Just make sure people that might run into those issues will get sensible error messages such as this:

     
  12. Geenz

    Geenz

    Joined:
    Sep 1, 2010
    Posts:
    99
    So would using modified generated surface shader code still work? I ask, because for those of us that do slightly out of the ordinary things (in this case, baking textures on the GPU with the correct light falloff and shadows) being able to modify the generated output of a surface shader is a convenient way to make our shaders accomplish some things that just aren't possible with the existing surface shader setup.
     
  13. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Yes. Looking at generated surface shader code, and pasting it into new/existing shader, and modifying it - that would all still work.

    Looking at final compiled shader assembly would still be possible, but probably not "pasting that into another shader and hand-editing the assembly" - that last bit quite likely won't work anymore.
     
  14. Geenz

    Geenz

    Joined:
    Sep 1, 2010
    Posts:
    99
    Right then. It all sounds good to me then - honestly I have no need or desire to modify the platform dependent shader assemblies or otherwise ship them. Anyone who knows about that stuff will just construct their own shaders based upon what they see there anyways. So long as copying generated surface shader output shader code, pasting it into a new shader, then modifying it still works I'm happy.
     
  15. VIC20

    VIC20

    Joined:
    Jan 19, 2008
    Posts:
    2,688
    What about new platform specific features that Unity does not understand yet? Like it was (or still is?) with GL_EXT_shader_framebuffer_fetch. I've used that by editing the compiled shader.
     
  16. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    I added support for GL_EXT_shader_framebuffer_fetch last week (in 5.0)...
     
    VIC20 likes this.
  17. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,521
    Hi,
    I just want to be informed ahead - a month or so would be fine, so I can make the necessary changes.
     
  18. pvloon

    pvloon

    Joined:
    Oct 5, 2011
    Posts:
    591
    See other topic, seems like a great change :)