OpenGL——对渲染的理解小结

最近断断续续，看了好久的OpenGL，终于有感觉有一点点入门了，渲染过程中，一些之前我很不理解的东西，变得有些清晰了。正如我当年研究CUDA并行计算的时候，从串行思想，到并行编程思想的过度，是最难的一步。

对我来说，学习的过程中遇到了一下难以马上弄通透的问题。

难点1：不知道如何将单个例子，结合成一个完整的渲染引擎

难点2：不能把Shader和CPU的流程联立在一起，不知道某个资源/数据，是从哪里来的。就算知道他是什么时候送到GPU的，也不知道GPU如何定位某个资源/数据。

难点3：难以建立起并行计算的思维方式

难点4：难以理解各种模板如何在多个批次之间发生作用。不能具象的去理解混合，测试的过程。不能够理解，FrameBuffer的真正含义。

难点5：难以建立起空间想象，不知道矩阵变换，如何将顶点，或其他数据，变换到不同的空间进行统一计算。

难点6：难以理解从Vertex到Fragment是如何过度的。

这有点像学习骑单车，最难得无非是保持平衡，知道保持平衡之后，就能把车子骑起来了。

串行编程思想，到并行编程思想，最难理解的是，你所执行的代码，不是一行行的便利每个像素或者顶点，没有先后顺序可言，这些操作是“同时”进行的，你的代码必须短小，尽量没有分支，每次分支，都会大大的降低效率，所谓并行，也不是真的并行，而是GPU有很多很多粒度更小的核心，如果说CPU有4-8核的话，那么GPU则是几百甚至上千个“小”的核心，当然相对于CPU，他的确是非常非常的“并行”了

你的“小程序”，无论CUDA程序也好，Shader也罢，是相对并行的，在这些很多个的GPU处理器上运行的，而绝大多数情况下，你在这些并行运行的小程序之间，彼此是不知道对方的存在的。彼此之间的数据，对彼此而言，都是"未知数"

——所以你不能直接做后期处理，而是需要先把一部分数据，写到一个FrameBuffer中区，这样FrameBuffer里面的数据作为共享数据，可以供后面运行的并行的小程序（也就是Shader）去获取，这FrameBuffer里面的数据，对于每个运行的“小程序”而言，就是可以利用的已知数了，并且通常这个FrameBuffer是只读使用的，你需要把计算结果写入到另一个FrameBuffer中去，比如最终渲染的BackBuffer。

而理解渲染流水线，最难的部分在于，我总是很难理解，那么多贴图，那么多模型，那么多Shader，要怎么在OpenGL里面区分？这乱糟糟的一大堆东西，OpenGL怎么才能一次画完。