Re: [情報] XBOX 下一代主機開發中

[kuma660224 (kuma660224)]

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


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.80.14.221
※ 文章網址: https://www.ptt.cc/bbs/XBOX/M.1500127422.A.12B.html
推 icarus0508: shader 在build 時哪是just in time coMpile
→ icarus0508: 而且 就算是用unity這種沒原始碼的  都要給ios andrio
→ icarus0508: d uwp 寫一堆shader特例了  我才剛寫過  最好是只寫一
→ icarus0508: 套
→ icarus0508: 而ue4這種 shader為平台特化更是常見
→ icarus0508: 你去trace ue4 code 底層 各平台能都都有差別的 sahde
→ icarus0508: r更是
→ icarus0508: 我說的build 是指 build pkg時  早coMpilw好了
推 icarus0508: 開發中後期  常是各平台最到最好  後期有時還會分版
→ icarus0508: 本....
推 jj95042: 樓上你推超過八行了
推 jj95042: 還有誰來告訴我這跟XBOX板有沒有關聯..
推 hades360: 快推，雖然我真的看不懂XD
→ hades360: 歡迎來到溫馨、歡樂、專業的Xbox 版
→ axisleon: 還好業界不乏活用知識的coder，而不是視API為準則,或許
推 Loser01: 推，免得被人家知道我看不懂
→ axisleon: exception不代表GPU不吃，我們才可以看到每一世代的傑作
→ axisleon: 而非被complier限制，code的藝術原PO可能要重新考慮下
→ axisleon: 您的論點只是教科書的信徒而已，請多作點實務。
→ axisleon: 人腦依然是創意無限的，硬體還不到可以完全取代的:)
推 nicetree: 老實說，我真得看不懂
推 hoos891405: 真的看不懂
→ kuma660224: 引擎打包時只是類似分封shader的變種
→ kuma660224: 不是真的compile成可執行的gpu原生指令
→ kuma660224: 先轉成hlsl/glsl的中間語言，最後loading
→ kuma660224: 時才透過驅動的JIT compile成可執行版
→ kuma660224: 所以build時打包並無做到最後JIT的階段。
→ kuma660224: 但寫code時，引擎能顯示你馬上改的效果。
→ kuma660224: 因為他立即丟到驅動顯示(沒build)就看到。
推 icarus0508: 那只有在editorz時  而已   built後成pkg shader是預
→ icarus0508: 先cimpile成各平台的可讀入binary  不是動態編譯的
→ icarus0508: 引擎editor可改 和最終無關 pc上 不論unity ue4預設
→ icarus0508: 都是dx在畫的  真正打包會重新build
→ kuma660224: 我們寫的時候就是在editor即時看修改結果
→ kuma660224: 重新build是全寫完，但他也不轉成最終執行碼
→ kuma660224: 是轉IL中間語言。最後執行期由驅動
→ kuma660224: 再JIT compile這些shader來跑。
→ sachajam: 買PC就好了....
→ SetaNoriyasu: 感謝提醒大家住橋下的troll不識字
→ SetaNoriyasu: 當然，我不是指本篇發文者。
推 icarus0508: build 成pkg和editor無關.... 已經是成品 所以是不會
→ icarus0508: 再重編了  你說的是editor看成品  在pc上才是動態給dx
→ icarus0508: 跑
→ kuma660224: 重點在於寫的時候就是馬上看到修改狀況
→ kuma660224: 一定挑毛病的話，就是成品上機後，用的
→ kuma660224: JIT compiler與硬體與PC不一樣。
→ kuma660224: 所以終端設備比較低階的話，精度可能更差。
→ kuma660224: 例如手機跑同樣shader少數某些狀況會出錯。
→ kuma660224: 因為有些連fp32實作都不一定做好做滿。