shader LOD快速生成具体是种怎样的技术？
A System for Rapid, Automatic Shader Level-of-Detail 添加评论 分享 按投票排序 按时间排序
4 个回答
赞同55 反对，不会显示你的姓名
Yong He ， CS PhD student 翟佳龙、王宇翔、知乎用户 等人赞同 谢邀。关于shader程序自动简化并不是什么新鲜的事情，之前已经有一些系统做到，例如Wang等人的Siggraph Asia 2014 paper " Automatic Shader Simplification Using Surface Signal Approximation".
我的这篇文章试图解决的一个问题是如何快速地简化一个shader, 并且决定要在什么时候（以及是否值得）用某个简化过的shader。为什么要强调快速？因为游戏开发的时候一个artist或者developer要创建大量的shader，你自动生成了一堆简化的版本，开发人员总要看一下是否合适并且以此迭代开发。在此之前所有类似的系统都采用了几乎是暴力搜索的方法来发现可以简化的地方，因此编译时间非常长（简化一个shader需要花费几个小时的时间）。
所以我的这个work主要要实现的目标是实现一个编译器以很快地自动简化shader，并且作为一个开发人员你能够认同编译器自动实现的简化（也就是编译器产生的简化后的shader跟人肉产生的差不多）。
为了实现这个目标，我们首先必须要让编译器可以做更多的事情。之前的文章提到了可以把shader code在vertex shader和fragment shader之间移动。但这其实还不够。我们引入了一个叫做Parameter Shader的东西，这是一个在CPU上执行的shader阶段。这样一来我就可以在执行draw call之前，在CPU上先算好一些东西直接传给GPU而不用在GPU上算。为什么需要这个额外的阶段呢？比如说你现在有一个很复杂的shader在fragment shader里面计算各种细节，然而这些细节到了远处就都看不到了，所以一个很自然地优化是去掉这些细节并且把它替换成一个常数。但是究竟替换成什么常数呢？在编译期间并不能确定，因此就搞一个parameter shader的东西，在运行的时候一旦shader的各项参数确定了，我就运行一下把这些可以变成常数的量算出来当作uniform 传给后面的GPU阶段。此外编译器还实现了一种新的code优化，叫做Approximate Common Sub-Expression Elimination，具体细节不说了，意思就是如果编译器发现两个expression算出来的值很接近，不管他们是不是真的symbolically equivalent，仍然考虑将一个表达式替换为另外一个表达式。
有了这些编译器可以执行的简化操作，剩下的就是如何快速的发现可以apply的简化操作。之前的文章都是使用一些stochastic search或者genetic programming的方法，这些都是很慢的。这篇文章讲了一个基于profile和heuristic based的贪心策略直接发现简化操作，这样编译器就能在一分钟之内完成并生成出很好的结果，而不需要运行几个小时。
时间比较紧，现在还在准备两周后的SIGGRAPH Asia Talk, 所以就只写这么多了。 编辑于 2015-10-23 1 条评论 感谢 分享 收藏 • 没有帮助 • 举报 • 作者保留权利 赞同9 反对，不会显示你的姓名
大萨比 ， SE游戏引擎工程师 Charlie、Juude、羊肉泡 等人赞同 正好在现场听了这个讲座。前天siggrapg asia 2015的course，今天刚回来。
这个研究是nvidia，bungie赞助和协同研发的。起因是现在的游戏shader数量庞大至十几万¹个(尤其是node based shader系统)。人工做lod几乎不可能，于是提出了自动优化工具。
比如：
x=a+b 简化成 x=a
x=sin(a) 简化成 x=a
texture sampling 简化成 constant
简化是基于profile，对每条指令进行评估，最后通过评价最终性能和误差决定简化策略是否有用。
具体实现手法看paper， @Yong He 本人也有解释。
私货感想：在应用和工程的角度看耗费如此人力物力开发这种自动化工具是否合算有待商榷。罪魁祸首是把shader的控制权交给artist的错，node base的弊端在此显现。如果从一开始shader是程序员可控的话不需要如此繁杂。另外现在的游戏计算最复杂的是光照系统，简化了十几万个shader也就提升了gbuffer的渲染时间和部分forward渲染。反而又增加了几十万shader，内存，加载时间，编译时间(开发效率)，QA怎么办？技术本身没错，离实际应用还是有距离的吧。
¹Destiny:16000个shader 编辑于 2015-11-06 1 条评论 感谢 分享 收藏 • 没有帮助 • 举报 • 禁止转载 赞同5 反对，不会显示你的姓名
钱康来 ， 五道口技工学院 c++苦手 rendering磨练中 高歌、Charlie、知乎用户 等人赞同 上周刚读了这篇文章，当时第一反应是想到了sa2011的一篇 virginia.edu 的页面
还有一篇 Automatic Shader Simplification Using Surface Signal Approximation (话说我有写邮件联系过作者，看看能不能要到可执行程序，不过...TAT)
最常见的LOD策略是简化模型，但这篇文章提供了简化shader的技术，从另一个层面降低消耗~
从最广义的来说，思路和别的程序自动优化一样(评估函数+程序变体策略)，但针对Shader又和普通的代码有所不同。这个文章提出的新变体策略很有意思~
摆碗坐等ing
其实你可以 @Yong He 来着... 编辑于 2015-10-22 添加评论 感谢 分享 收藏 • 没有帮助 • 举报 • 作者保留权利 赞同4 反对，不会显示你的姓名
叛逆者 ， GPU Gems 2译者，图形专家 高歌、知乎用户、知乎用户 等人赞同 @Yong He 的大作，当然应该问 @Yong He 了。
我还没看paper，只是看了video。基本上，就是个shader简化系统。随着lod的增加，自动去掉shader里的高级渲染功能，达到降低远处物体计算量的目的。顺序是，height/normal texture->roughness texture->abedo texture->constant color。