XBOX 下一代主機開發中 - XBOX

Table of Contents

新一代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....


--

All Comments

Victoria avatarVictoria2017-07-18
shader 在build 時哪是just in time coMpile
Hazel avatarHazel2017-07-19
而且 就算是用unity這種沒原始碼的 都要給ios andrio
d uwp 寫一堆shader特例了 我才剛寫過 最好是只寫一

而ue4這種 shader為平台特化更是常見
Ivy avatarIvy2017-07-22
你去trace ue4 code 底層 各平台能都都有差別的 sahde
r更是
Leila avatarLeila2017-07-27
我說的build 是指 build pkg時 早coMpilw好了
Jake avatarJake2017-07-27
開發中後期 常是各平台最到最好 後期有時還會分版
本....
Eden avatarEden2017-07-31
樓上你推超過八行了
Annie avatarAnnie2017-08-02
還有誰來告訴我這跟XBOX板有沒有關聯..
Emma avatarEmma2017-08-05
快推,雖然我真的看不懂XD
James avatarJames2017-08-10
歡迎來到溫馨、歡樂、專業的Xbox 版
Rosalind avatarRosalind2017-08-12
還好業界不乏活用知識的coder,而不是視API為準則,或許
Irma avatarIrma2017-08-17
推,免得被人家知道我看不懂
Harry avatarHarry2017-08-20
exception不代表GPU不吃,我們才可以看到每一世代的傑作
Caitlin avatarCaitlin2017-08-21
而非被complier限制,code的藝術原PO可能要重新考慮下
Liam avatarLiam2017-08-25
您的論點只是教科書的信徒而已,請多作點實務。
Ingrid avatarIngrid2017-08-26
人腦依然是創意無限的,硬體還不到可以完全取代的:)
William avatarWilliam2017-08-27
老實說,我真得看不懂
Gilbert avatarGilbert2017-08-28
真的看不懂
Regina avatarRegina2017-09-01
引擎打包時只是類似分封shader的變種
不是真的compile成可執行的gpu原生指令
Lauren avatarLauren2017-09-03
先轉成hlsl/glsl的中間語言,最後loading
時才透過驅動的JIT compile成可執行版
Audriana avatarAudriana2017-09-04
所以build時打包並無做到最後JIT的階段。
但寫code時,引擎能顯示你馬上改的效果。
因為他立即丟到驅動顯示(沒build)就看到。
Blanche avatarBlanche2017-09-06
那只有在editorz時 而已 built後成pkg shader是預
先cimpile成各平台的可讀入binary 不是動態編譯的
Regina avatarRegina2017-09-06
引擎editor可改 和最終無關 pc上 不論unity ue4預設
都是dx在畫的 真正打包會重新build
Caitlin avatarCaitlin2017-09-10
我們寫的時候就是在editor即時看修改結果
Aaliyah avatarAaliyah2017-09-13
重新build是全寫完,但他也不轉成最終執行碼
Lauren avatarLauren2017-09-13
是轉IL中間語言。最後執行期由驅動
再JIT compile這些shader來跑。
Ida avatarIda2017-09-13
買PC就好了....
Caitlin avatarCaitlin2017-09-16
感謝提醒大家住橋下的troll不識字
Madame avatarMadame2017-09-18
當然,我不是指本篇發文者。
Eden avatarEden2017-09-19
build 成pkg和editor無關.... 已經是成品 所以是不會
再重編了 你說的是editor看成品 在pc上才是動態給dx
Queena avatarQueena2017-09-24
重點在於寫的時候就是馬上看到修改狀況
Ida avatarIda2017-09-24
一定挑毛病的話,就是成品上機後,用的
JIT compiler與硬體與PC不一樣。
Edith avatarEdith2017-09-29
所以終端設備比較低階的話,精度可能更差。
Frederica avatarFrederica2017-10-02
例如手機跑同樣shader少數某些狀況會出錯。
因為有些連fp32實作都不一定做好做滿。