标签： render

在学完并实现路径追踪之后，即使增加了多线程渲染，在SPP=1024的情况下，依然需要30+分钟才能渲染一帧。

为了更快的渲染速度 ，我试图通过使用GPU的CUDA SDK来加速渲染。然而测下来竟然还没我的CPU跑的快，一方面我没有更好的显卡，另一方面我也不太确定是不是我CUDA使用错误所致。再加上就算使用GPU也不可能达到每帧秒级渲染。于是GPU的学习就搁置了。

然而在最近研究Splat地形渲染方案时, 我无意间发现了一个现象。测试地形为4层混合，在所有Texture都不开Mipmapping的情况下, FPS只有30左右，而开了Mipmapping之后，FPS可以稳定在60. 这激起了我强烈的好奇心，终于将了解GPU的运行架构提上日程（又产生了一次PageFault, 本来我在学习《mysql是怎么运行的》这本书，都已经快把B+ Tree看完了) 。

对照《GPU 精粹1》中的【28.2节 定位瓶颈】得出一个结论，如果Texture Filtering会影响FPS， 那么就说明瓶颈在Texture Bandwidth。

这引出我的第一个问题，Texture Bandwidth到底是什么，为什么Mipmapping会影响Texture Bandwidth？

我最开始以为是从CPU到GPU之间传输图片的带宽，越查资料越确定不是这样。

在找到影响FPS的因素之前，其实我大约花了一天试验了各种设置（这就是基本功不够扎实的现象，没有头绪各种试），甚至在FPS达到60时，我都搞不清到底是改了哪个设置变好的。

当然在这期间我也查了很多资料，其中最重要的两个点是说，对于Splat地形方案，他们都会提到减少Sampler的个数，并且提到使用 TextureArray可以改善性能。使用TextureArray可以改善性能的原因是因为它减少了bindtexture的次数，而为什么要减少SamplerState我当时并没有找到依据。

这就引出了第二和第三个问题，为什么要减少SamplerState的数量，是不是性能问题？bindtexture为什么会很“贵”？

直到昨天我发现了一篇NVIDIA讲解GPU架构的文章， 这篇文章虽然不长，但是指出了各种我们在写shader时需要知道的要点。

---

我先简要概述这篇文章，然后试图来解释这三个问题。

在GPU中有Warp Scheduler, thread, register file, TMU, TextureCache等概念。

Warp Scheduler是最基本的调度单元，也就是说整个Warp Scheduler中的thread一直在执行“齐步走”逻辑. 如果有一个Thread需要换出（switch out)比如等待内存加载), 整个Warp Scheduler的所有Thread都会换出(switch out)。

只要有一个Thread 的if () 判断为真，那所有的Thread都需要执行if为真的逻辑，即使有的Thread的if判断为假，也需要等待if为真的Thread都执行完才执行else, 而之前那部分if为真的Thread同样需要等待else的语句执行完再继续“齐步走”。

每个Warp Scheduler会有32个Thread。这么理解下来其实每个Warp Scheduler就相当于一个具有32通道的SIMD指令(英伟达把他叫做SIMT)。

每个Thread都有自己的寄存器， 这些寄存器都从register file进行分配，如果shader使用过多的寄存器，就会导致更少的Warp Scheduler和更少的Threads, 而更少的Warp Scheduler则意味着GPU的Core可能跑不满(类比操作系统，如果所有Thread都Sleep, 那CPU就在空转是一样的), GPU的性能就得不到发挥。

根据Wiki的解释，纹理采样主要是通过TMU模块进行执行的，TMU模块是一种有限的硬件资源， 因此你采样更多（不一样的）纹理，就需要消耗更多的周期。

纹理采样除了计算之外，还需要加载纹理数据，TMU会首先向Texture Cache中去加载，如果Cache Miss就会从L2加载到Textuer Cache, 如果L2也Cache Miss,就会从DRAM(显存)中加载纹理，然后依次填充L2和Texture Cache.

根据英伟达说明的GF100内存架构从Thread读到Texture Cache只需要几十个周期，而从L2向DRAM加载则需要几百个周期。在这些周期内，需要采样纹理的Warp Scheduler都需要被换出(swap out)。

至目前为止，其实已经能解释前两个问题了：

1. Texture Bandwidth到底是什么，为什么Mipmapping会影响Texture Bandwidth？

   Texture Bandwidth其实就是指Texture 从DRAM到L2和L2到Texture Cache的加载带宽

   没有使用Mipmapping之前，我们地形的每一层图片尺寸都是10241024的图片，并且被渲染出的像素尺寸只有256256大小, 这样在渲染相邻的pixel时被采样的texel在内存中是不连续的, 因此在纹理采样过程中会频发触发Texture Cache Miss, 每次Cache Miss都需要额外的周期从L2或DRAM中重新加载。

   使用了Mipmapping之后，GPU可以根据当前的渲染情况来判断采用哪一个Mip Level。当选择合适的Mip Level之后, 相邻的pixel对应的texel也会尽可能的相邻，可以极大的缓解Texture Cache Miss的状况。

2. 为什么要减少SamplerState的数量，是不是性能问题？

   根据微软文档显示，Direct3D 11中SamplerState最大上限为16，但是采样纹理数最大上限为128。可能是因为别人使用Splat方案时，地形层数远超16层。当然也有可能是性能问题，但是我没查到具体依据。

   根据英伟达的说明，具体执行采样是由TMU来执行的，而根据SIMT的特性，同一时间只有一个纹理会被采样，所以理论上SamplerState的多少并不会影响TMU的执行和并发度。

   我反汇编了shader(D3D版本)， 看到一个现象，每当我定义一个SamplerState, 就会有一行dcl_sampler的语句，我查了一下MSDN， 发现这个语句是用来声明sampler寄存器。所以如果非要说减少SamplerState可以提高性能，那原因应该就是，使用更多的sampler寄存器，可以获得更多的Warp来增加GPU的并行度。

3. 为什么bindtexture开销比较大？
   暂时未找到合理的解释

---

在查资料过程中，有两个额外的收获：

bindtexture并不是从CPU向GPU上传图片，在opengl中上传图片是使用glTexImage2D来实现的，这时图片只在显存中。

在fragment阶段，并不是每一个像素都被任意分配到一个Thread然后并行执行的。

一个Warp Scheduler被分成8*4个线程组，每2×2的像素块，被分配给一个数量为4的Thread组, 也是就说每2×2的像素块一定被分配给在同一个Warp Scheduler中的4个Thread。具体原因英伟达的文章上并没有细说。但是大概意思是，比如在决定mip level时，除非这4个像素uv跳跃太大，不然可以只用计算一次mip level就可以了。

在网上查资料时，无意间发现了一门课叫《现代计算机图形学入门》。于是事隔将近3年后，我再一次尝试图形学入门。这次学习从8月20号开始，一直到10月11日，约持续了一个半月。

但是这次的学习体验和上次是完全不同的，最直接的感受有3点。

1. 《现代计算机图形学入门》要比《3D游戏编程大师技巧》中的内容现代的多，内容和知识体系都更全面。

2. 现代计算机的性能远超《3D游戏编程大师技巧》著作当时，因此很多为了提高性能的Trick已经没有必要使用。这会使我们花费大量精力在局部细节，而不能窥其全貌。一个最简单的例子就是，一个简单的lerp就让我花费的大量时间来调试。

3. 《现代计算机图形学入门》把主要精力都放在了如何渲染上，至于一些优化手段很少提及，比如三角形裁切，剔除等。这只是一些加速的优化手段，并不影响最终的渲染效果。这些优化在入门阶段，其实并不重要。而在《3D游戏编程大师技巧》中我们会沉浸在各种优化技巧中，而失去了渲染的全貌。

下面记录一下这次学习的新收获。

---

1. 透视矫正（光栅化）

在纹理采样时，所有3维坐标都已经被投影到一个2维平面，但是纹理坐标属于3维空间。因此2维坐标下的插值系数不能用在3维坐标进行插值， 下面先来看一下为什么不能插值。

我们先定义q(x,y,z,1)为3维坐标，r(x,y,z,w)为齐次坐标，s(x,y,z, 1) 为投影坐标。

Xr = aXq + b; Yr = cYr + d; Zr = e * Zq + f; Wr = g;

q’ = lerp(q) = q1 + (q2 – q1) t;
r’ = lerp(r) = r1 + (r2 – r1) t = q’ (a,c,e) + ((b,d,f) + ((b,d,f)’ – (b,d,f)) t)

可以看到虽然q到r的变换不是线性变换，但是有一部分变量是由q*t来贡献的，因此在齐次空间下直接对3维空间坐标进行插值，并没有太大的问题。

再来看一下齐次坐标到投影坐标的变换。

Xs = Xr / Wr; Ys = Yr / Wr; Zs = Zr / Wr;

先对齐次坐标r进行lerp，得到r’ = (lerp(Xr), lerp(Yr), lerp(Zr), lerp(Wr)).

再对r’做投影变换,得到s’ = lerp(s) = (lerp(Xr)/lerp(Wr)， lerp(Yr)/lerp(Wr), lerp(Zr)/lerp(Wr), 1) = lerp(r) / lerp(Wr).

这与直接对s做插值是一样的（在投影坐标系之后，不会再次执行齐次除法）。

根据q’和r’的公式推导，可以看到lerp(r)和lerp(q)是可以共用插值系数的。

再根据s’的公式推导，可以得出lerp(s) 和 lerp(q) 的插值系数多了一个lerp(Wr).

这就是为什么，在投影坐标系对3维坐标系下的坐标做插值时，需要先做一次投影除法，将其变换到投影坐标系下，做完插值后，再除以lerp(1/w)来变回3维坐标系。

有一点需要额外提的是，有些资料提到除以lerp(1/z)也可以。但这其实不正确，因为投影变换本质上压缩了z坐标的值，相比w(实际上是3维空间下的z)来讲，会有更大误差的。

2. 光线追踪

这次学习过程中，最大的收获就要数光线追踪了。在之前的印象中，我一直以为，渲染就是模型空间->世界空间->投影空间->屏幕空间坐标系之间的转换然后再将其光栅化成像。

这是我第一次了解到，原来另一种更好的成像方式叫光线追踪，甚至还有更真实的路径追踪。

3. 一些零碎的额外收获

正交平移矩阵用的是坐标，所以如果相机本来就在原点那么(l+r) / 2 刚好也等于0。可能这就是为什么要选用[-1,1] 而不是[0,2] 来定义NDC的原因。

右手坐标系，脸朝向的地方为z = -1。因此在计算z深度时需要对z做反转。BUT，在计算投影矩阵时，我们一般会对进屏幕和远平面取负。因此在光栅化时就不需要再次补偿了。

使用一个矩阵M对一个三角形的三个顶点做变换后，使用M来变换法线向量有可能会使法线向量变形。由于切线向量就是三角形的一个边，因此切线不会发生形变。因此，当需要变换法线时，需要额外算出一个矩阵。具体计算公式在《Mathematics for 3D Game Programming and Computer Graphics Third Edition》中第4.5节有详细推导。

球面与射线相交处的法线，并不是从从射线原点到球心的向量。因为射线可能斜着打中球面（甚至会只擦中一点)

中位线和法线的夹角并不能代表出射光线和视线的夹角，是为了更好的光照效果，blin-phong故意引入的。其中一个副作用是，运算更快了。

在微表面模型下，不同的粗糙程度会有不同的概率密度函数，这是因为光线的分布不一样。例如在镜面反射下，大部分光线能量都会沿着某一个特定的方向射出。其他方位的光线概率密度就会特别低。

前一段时间打算写一个完整的游戏, 客户采用Unity3D引擎, 服务端则采用我自己的Silly网络框架。

然而，最终这个项目烂尾了。烂尾的原因有很多，比如缺少资源，在不断寻找资源过程中使自己开发的热情消失殆尽等。但更为重要的是，我发现在使用Unity3D过程中，除了拼接UI逻辑时，没有碰到太大困难外。在实现一些3D效果时竟处处掣肘，甚至连最简单的贴花系统都实现不了。

而此时我的图形学背景是，《3D数学基础：图形与游戏开发》，《DirectX9.9 3D游戏开发编程基础》，《Unity Shader入门精要》和其他一些Unity操作手册。

这使我意识到，我的图形学知识结构出现了根本性问题。之后偶然的一个机会，我在网上接触到了“光栅化软件渲染器”的概念。深挖之下，发现这正是我目前所缺少的知识。

《3D数学基础：图形与游戏开发》介绍了“物体坐标系”，“世界坐标系”，“摄相机坐标系”等各种坐标系，以及如何实现一个数学引擎来实现各坐标系之间的转换。

《DirectX9.9 3D游戏开发编程基础》则介绍的是我们如何使用DirectX提供的各种API来使用相机，光照等各种抽象好的模型。

但是，这两本书之间存在着明显的断层，很难明白在调用DirectX提供的API之后，底层渲染是如何工作。例如，一个物体到底是如何一步一步画到屏幕上的，纹理是如何映射到3D物体上的，Shader到底是如何工作等。虽然这几本书，每一本都会讲一遍渲染流水线，但是这些细节很难被提到。

从零实现一个“光栅化软件渲染器”可以完美的填充这个空白，哪是一个效率很低的”软件渲染器”，这对理解3D渲染是如何工作起着至关重要的作用。幸运的是刚好有一本《3D游戏编程大师技巧》讲的就是这些内容（虽然我不是很认可他的章节安排:D)。

---

按照《3D游戏编程大师技巧》实现自己的软件渲染器的过程中，数学引擎，坐标系转换，甚至连光照都没碰到什么大问题，在最后一步将屏幕坐标系下的2D三角形光栅化时，踩了一个3连坑，导致一下耽搁了半个月才终于在昨天找到问题所在。

在光栅化的过程中，为了防止重复绘制相素，一般会采用左上(top-left)填充规则。例如绘制一个对角定点为(0, 0), (6,6)的正方形时，会避免为第6行和第6列绘制相素。大概实现伪码如下：

//void draw_pixel(int x, int y, int color);
int x, y;
for (y = 0; y < 6; y++) {
        for (x = 0; x < 6; x++) {
                draw_pixel(x, y, color);
        }
        ... do something ...
}

然而，看实简单的代码背后，却隐藏着各种坑。

在经过渲染流水线计算之后的图元（一般为三角形)坐标一般为float类型，而且大部分情况下都会有小数部分，比如(94.65, 331.64)。这时就需要制定一个规则，是向上取整（即将坐标变成(95,332)）或者向下取整(即将坐标变成(94,331))。

为了省事，我的第一版直接采用了相下取整进行坐标映射，渲染伪码如下(这里仅仅将x,y的类型从int变成了float，因为向draw_pixel传参时，将float转成int采用的就是去1法)：

//这里仅假设光栅化一个平顶三角形【（x0,y0), (x1, y1), (x2, y2)】并且(x0 < x1 && y0 == y1 && y0 < y2)。
//void draw_pixel(int x, int y, int color);
void draw(float x0, float y0, float x1, float y1, float x2, float y2)
{
        float x, y;
        float h = y2 - y1;
        float xleft_step = (x2 - x0) / h;
        float xright_step = (x2 - x1) / h;
        xleft = x0;
        xright = x1;
        for (y = y0; y < y2; y++) {
                for (x = xleft; x < xright; x++) {
                        draw_pixel(x, y, color);
                }
                xleft += xleft_step;
                xright += xright_step;
        }
}

然而这是不对的，一个最简单的例子，当【xstart=9.1，xend = 18.5】时，由于采用去1法映射相素坐标，因此理论上x方向绘制的相素坐标最大值应该小于18。但是当x=18.1上仍然会执行draw_pixel函数，此时经过传参转换后，x的值为18，这违反了左上规则（y轴同样存在这个问题)。

改良后第二版如下：

//这里仅假设光栅化一个平顶三角形【（x0,y0), (x1, y1), (x2, y2)】并且(x0 < x1 && y0 == y1 && y0 < y2)。
//void draw_pixel(int x, int y, int color);
void draw(float x0, float y0, float x1, float y1, float x2, float y2)
{
        int x, y;
        float h = y2 - y1;
        float xleft_step = (x2 - x0) / h;
        float xright_step = (x2 - x1) / h;
        xleft = x0;
        xright = x1;
        for (y = (int)y0; y < (int)y2; y++) {
                for (x = (int)xleft; x < (int)xright; x++) {
                        draw_pixel(x, y, color);
                }
                xleft += xleft_step;
                xright += xright_step;
        }
}

但是这依然不对, 当(x0, y0) = (2.1, 0.5）并且(x2, y2) = (7.1, 5.5) 时，代码实际绘制的第一个相素坐标为(2，0)。

但是根据直线【(x0, y0)，（x2,y2)】的斜率可以算出当y=0时，x的值应该为1.1，换句话说理论上应该绘制的第一个相素坐标为(1, 0)。因此上述代码完美的将相素坐标(1,0)给避过去了，大部分情况下这种现象表现为，两个相邻的图元（这里指三角形)之间会有一条空白线（即两个三角形均没有绘制这条线)。

因此，当我们将y向下取整时，需要根据舍去去的小数修正x的值（因为斜率可能会非常大，有可能y只舍去了0.1,但是x会偏差好几个像素)。

修正版的代码如下：

//这里仅假设光栅化一个平顶三角形【（x0,y0), (x1, y1), (x2, y2)】并且(x0 < x1 && y0 == y1 && y0 < y2)。
//void draw_pixel(int x, int y, int color);
void draw(float x0, float y0, float x1, float y1, float x2, float y2)
{
        int x, y;
        float h = y2 - y1;
        float xleft_step = (x2 - x0) / h;
        float xright_step = (x2 - x1) / h;
        xleft = x0 - （y0 - (int)y0) * xleft_step;
        xright = x1 - (y0 - (int)y0) * xright_step;
        for (y = (int)y0; y < (int)y2; y++) {
                for (x = (int)xleft; x < (int)xright; x++) {
                        draw_pixel(x, y, color);
                }
                xleft += xleft_step;
                xright += xright_step;
        }
}

你以为事情就结束了么= =！

当直线【(x0, y0)，（x2,y2)】的斜率为20时，y坐标向上取整时舍去y坐标0.5，x坐标会向左偏移10个坐标。这样原本(x0, y0) = (100, 10.5)的坐标经过取整后就会变成(80, 10)。这种错误大部分情况下表现为，三角形的顶部或底部突然多出一条直线。将所有逻辑改为向上取整，即可解决此问题。因为向上取整会保证所有坐标点都会落在原始三角形内，而向下取整会导致某些不在三角形内部。

修正版代码如下：

//这里仅假设光栅化一个平顶三角形【（x0,y0), (x1, y1), (x2, y2)】并且(x0 < x1 && y0 == y1 && y0 < y2)。
//void draw_pixel(int x, int y, int color);
void draw(float x0, float y0, float x1, float y1, float x2, float y2)
{
        int x, y;
        float h = y2 - y1;
        float xleft_step = (x2 - x0) / h;
        float xright_step = (x2 - x1) / h;
        xleft = x0 +（ceil(y0) - y0) * xleft_step;
        xright = x1 + (ceil(y0) - y0) * xright_step;
        for (y = ceil(y0); y < ceil(y2); y++) {
                for (x = ceil(xleft); x < ceil(xright); x++) {
                        draw_pixel(x, y, color);
                }
                xleft += xleft_step;
                xright += xright_step;
        }
}

至此，三连坑才算被踩完.

---

3月25日补充：

在进行仿射纹理映射时, 同样踩了两个坑。

1. 当y坐标向上取整时，相应的uv坐标需要采用与xleft和lright一样的算法进行修正。
2. 所有的纹理坐标范围是(0.0~1.0），在向位图坐标转换时（假设位图宽度为64×64）需要转换为(0, 63)

完整的修复代码在这里