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

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

Links booklink

Contact Us: admin [ a t ] ucptt.com