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

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

背景

下面主要記錄一些引擎中的材質(zhì)系統(tǒng)以及Shader編譯上的思考。

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

Shader編譯上的差異

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

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

再看Unity3D的Shader編譯流程：

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

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

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

 

Unity與UE4材質(zhì)系統(tǒng)的差異

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

UE4的基礎(chǔ)Shader修改也容易導(dǎo)致大量材質(zhì)重新編譯，當(dāng)然你也可以使用Custom Shader Plugin或者自定義Shader節(jié)點實現(xiàn)相應(yīng)的功能，

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

Shader語言上的思考

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

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

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