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