新一代GPU針對不同精度
有不同算力或優化,就業界開發多年經驗，應該是軟硬體必走趨勢。
雖然PC用的北極星架構沒有雙倍fp16運算能力，但它也已經實作"fp16暫存器"。
讓gpu有限的register用在刀口上，提升效率。
(以前硬體很笨，要fp16只能存成fp32，佔2倍暫存器，不夠用就開始影響效能)
如果全用fp32寫shader,不代表追求高品質
只代表你笨，白耗費寶貴暫存器可能影響效率。連神仙寫的compiler，都救不了無謂的浪
費。
如果講全用fp16衝效能而影響畫質，
那是腦補，哪家TA寫code時不能
視精度需求而使用?
優化已經通行很久，只是以前你不知道,
而且以前優化能有多少效果因平臺而異。
但由於繪圖演算法是能跨平臺的。
大部分開發商也不是這輩子只做一平臺。
所以在撰寫時是根據泛用優化原則，
反正故意用全精度也不會比較好寫，
之後開發其他平臺時等於找自己麻煩。
至於能否因為GPU支援fp16，
遊戲繪圖就跑2倍快?
我是不認為，因為沒人會全用fp16.
但這其實不重要，反正確實有幫助。
所以GPU是一定往這方向發展，
就算不是加速成200%，誰會拒絕更有效率?
例如你從domain shader/vertex傳入的
各種插補向量值(用於後續)，因插補而長度改變。
必須要在PixelShader正規化(長度歸為一)
明知其向量xyzw範圍不可能超過half的範圍,(因為你在VertexShader早以對向量正規化，
已知它範圍在哪，不可能有超出。)
硬要用fp32來算normalize不會讓這顆pixel比較"帥"。
拉高無謂的精度，也對畫質0影響0加分。
所以早期nvidia有個fp16 normalize unit
專門加速這種運算，後來新架構拔掉。
但拔掉不是因為精度，而是那種固定運算單位，不能泛用跑其他指令。隨著shader複雜化
，該指令運用比例下滑，留那種
沒泛用性的特殊單位，反而B>Z.
佔用電晶體卻常常閒置。
通常優化原則ꀨ各家引擎文件應都有說)
世界座標的頂點positions 通常得用float
(因為"世界"範圍太廣，顯然不能低精度)
貼圖座標texture coordinates 最保險能float ，但很多狀況用half甚至fixed也行。
因為uv mapping範圍是事先就決定。
你會知道這shader用到的範圍沒超過。
至於其他向量或color全都用half就很足夠。因為向量長度是通常都是1...不是1你也得讓
它變成1....
早年PC開發較不在乎有沒好好指定精度，是因以前GPU硬體很笨。
(省電晶體簡化設計,衝效能只靠拼sp數量)
比較舊的技術資料甚至告訴你，
不管怎麼設置速度與佔用資源都不變。
因為早期PC顯核,是不管shader用float或half，內部強制全用fp32運算，並且全用fp32暫
存...
但幾年前開始慢慢不是這樣了。
似乎從硬體資源更緊的手持顯核開始帶動，發現好用而延伸到PC顯核，會導致
shader演算硬體稍微變複雜，但有效率。
部分原因可能是半導體製程的進化速度
遇到瓶頸變緩，PC暴力堆積sp的速度變
慢,開始必須更在意用有限資源提升效率。
GPU硬體也不一定要完整支援到翻倍fp16算力,才能有意義。
即使只是GPU硬體懂得運用fp16來暫存，
就能減少register pressure.
.....效率就是生命。
現在主流引擎下的shader多是能跨平臺泛用的。只是你要不要功能全開。
同一個shader運用在不同平臺或遊戲要省效能，通常是減少運算複雜度,關掉不必要的功
能(特效).
精度本身不用刻意改變。因為你本來就照不影響畫質的優化原則去設精度。
不能改低的再怎樣也不能改(畫面會出錯)
Shader都是Just in time compiler
即時改即時看，就馬上看到修改效果品質。
出錯你眼睛正常不會不知道。
例如uv貼圖座標. ，超出範圍不是品質變化，而是貼圖完全出錯出包，像是大bug....

shader 在build 時哪是just in time coMpile而且 就算是用unity這種沒原始碼的 都要給ios andriod uwp 寫一堆shader特例了 我才剛寫過 最好是只寫一套而ue4這種 shader為平台特化更是常見你去trace ue4 code 底層 各平台能都都有差別的 sahder更是我說的build 是指 build pkg時 早coMpilw好了開發中後期 常是各平台最到最好 後期有時還會分版本....

樓上你推超過八行了還有誰來告訴我這跟XBOX板有沒有關聯..

快推，雖然我真的看不懂XD歡迎來到溫馨、歡樂、專業的Xbox 版

還好業界不乏活用知識的coder，而不是視API為準則,或許

推，免得被人家知道我看不懂

exception不代表GPU不吃，我們才可以看到每一世代的傑作而非被complier限制，code的藝術原PO可能要重新考慮下您的論點只是教科書的信徒而已，請多作點實務。人腦依然是創意無限的，硬體還不到可以完全取代的:)

老實說，我真得看不懂

真的看不懂

引擎打包時只是類似分封shader的變種不是真的compile成可執行的gpu原生指令先轉成hlsl/glsl的中間語言，最後loading時才透過驅動的JIT compile成可執行版所以build時打包並無做到最後JIT的階段。但寫code時，引擎能顯示你馬上改的效果。因為他立即丟到驅動顯示(沒build)就看到。

那只有在editorz時 而已 built後成pkg shader是預先cimpile成各平台的可讀入binary 不是動態編譯的引擎editor可改 和最終無關 pc上 不論unity ue4預設都是dx在畫的 真正打包會重新build

我們寫的時候就是在editor即時看修改結果重新build是全寫完，但他也不轉成最終執行碼是轉IL中間語言。最後執行期由驅動再JIT compile這些shader來跑。

買PC就好了....

感謝提醒大家住橋下的troll不識字當然，我不是指本篇發文者。

build 成pkg和editor無關.... 已經是成品 所以是不會再重編了 你說的是editor看成品 在pc上才是動態給dx跑

重點在於寫的時候就是馬上看到修改狀況一定挑毛病的話，就是成品上機後，用的JIT compiler與硬體與PC不一樣。所以終端設備比較低階的話，精度可能更差。例如手機跑同樣shader少數某些狀況會出錯。因為有些連fp32實作都不一定做好做滿。