跨平臺引擎Shader編譯流程分析是怎樣的

本篇文章為大家展示了跨平臺引擎Shader編譯流程分析是怎樣的，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

背景

下面主要記錄一些引擎中的材質系統以及Shader編譯上的思考。

Unity和Unreal都是跨平臺的游戲引擎，而跨平臺的基礎包括材質描述語言(Shading Language)以及渲染器。在Shader語言上，Unity和Unreal都選擇了廣為使用的HLSL，這也不可避免的需要實現跨平臺的Shader編譯方案。

Shader編譯上的差異

先看UE4.22的shader編譯流程：

首先，Epic Games是一家擁有悠久歷史的游戲引擎公司，UE4自己實現了SM5 Level的HLSL前端（使用Flex/Bison工具），結合MesaIR以及開源的Glslang庫實現了一套多API兼容、多設備特性兼容的語言翻譯器。

再看Unity3D的Shader編譯流程：

Unity是一個小巧，并擁有精致內核的引擎，在編輯器層面實現了D3DCompiler.dll的跨平臺（參考了Wine的PELoader），然后再通過DXBC翻譯至多平臺Shader語言，同時也能支持一些設備特性，由于D3DCompiler.dll是X86的指令，所以它的編譯方案不支持移動設備上的HLSL Compute Shader編譯。

現在到了2019年，微軟基于LLVM/Clang生態開源了DirectXShaderCompiler，Google貢獻了SPIRV的生成器，NVIDIA也在這個項目上提供了RTX SPIRV的翻譯，DXR/RTX也將要開始推廣了，如何翻新新的跨平臺Shader編譯方案？

目前，開源的支持HLSL編譯的方案主要有微軟的DXC以及Khronos的Glslang兩個項目，DXC HLSL是微軟官方和Google維護，Glslang HLSL主要是Google維護。

 

Unity與UE4材質系統的差異

Unity這邊主要使用ShaderLab作為材質描述語言，ShaderLab可以描述RenderPass以及RenderPipelineState，這對于未來渲染起的擴展是有益的，比如Prebake PipelineState Object；而UE4使用可視化節點表達式描述材質，兩者各有優缺點。UE4的材質系統更適合美術使用，但控制不好容易排列組合爆炸，拖慢項目迭代進度；Unity的ShaderLab的排列組合更好控制（手動），這也帶來了更快的迭代速度。

UE4的基礎Shader修改也容易導致大量材質重新編譯，當然你也可以使用Custom Shader Plugin或者自定義Shader節點實現相應的功能，

Unity 2017/8之后，官方也提供了與UE4類似的節點式材質編輯器。

Shader語言上的思考

目前主流的實時渲染Shader文本語言主要有HLSL，GLSL，Metal SL，他們都基于類C語言發展而來，天生不能很好的支持模塊化Shader編譯（編程語言模塊化的支持能一定程度提升編譯效率）。因此曾經發明了CG語言的NVIDIA，在自家的Falcor渲染器上又基于HLSL的語法發明了Slang語言，來更好地支持模塊化以及硬件特性擴展。

Metal Shading Language是基于C++14而來，Metal編譯器生成的Binary Shader實際上是LLVM BitCode，雖然Metal SL編譯器閉源，但網上也人在LLVM的基礎上實現了開源的Metal SL編譯器（Floor），目前的Metal API不提供Binary的Shader導出，得必須使用MacOS的Metal離線編譯器才能生成Binary Code（用于Shader Cache提升加載速度），因此Floor或許是一個值得關注的項目。

上述內容就是跨平臺引擎Shader編譯流程分析是怎樣的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。