简单调研了下，感觉 vulkan 标准的支持程度并没有想象中的那么低，所以其实能直接上 vulkan。
虽然一直很想试试听起来超酷的 vulkan，可惜我对 OpenGL 实在是爱得深沉，等我把最近的一个 OpenGL 项目做完（用 4.x API），再学习 vulkan。

今天为了 overhead 忙的焦头烂额，为了解决 gpu 利用率低的问题我写了巨量的代码对 draw call 进行排序与合并，用空间换时间，实现了线性的时间复杂度，渲染 10000 个物体，一帧只有几个 draw call， profiling 下来发现 gpu time 大大下降，但 cpu time 多了 4～5 ms —— 直接把帧率压到 200 帧以下了。
这…完全是把 gpu 的 overhead 给移到 cpu 了！甚至是负优化。
所以我非常好奇以前玩的游戏是如何跑这么高的帧数的。它们每帧需要渲染的对象很可能远远多于 10000，但在十年前的老电脑上跑的帧率能达到数百。
一定是哪里做得还不够好。

多线程暂不考虑，因为 OpenGL 在多线程环境下容易出奇奇怪怪的问题，即便所有的 API 调用都处于初始创建 context 的线程中也是如此。硬要用多线程的话，应当把并行的范围局限在 subsystem 内，但目前性能的瓶颈在 rendersystem，偏偏这个系统的并行化不太好实现…

明天把所有 direct rendering 都换成 indirect rendering，看看对性能有多少提升。

才发现 edge 给文本高亮加了弧形的边缘治好了我多年的强迫症

刚刚忍不住看了一些 vulkan tutorial，记录一下心得。
在有 OpenGL 基础的情况下 vulkan 并没有像网上说的那样恐怖，尽管渲染一个简单的三角形相对 OpenGL 来说的确需要花不少力气，但每个步骤都很 intuitive，而且我惊喜地发现大部分的操作在 OpenGL 中都有类似的 API 与之相呼应。

我注意到 Vulkan 的 API 相比 OpenGL 有一个明显的不同之处，就是它会即时返回某一操作的执行状态（成功 / 失败），而 OpenGL 中则需要进行主动的 query

swap chain 目前看下来有点像封装过的 double buffer，每次渲染时需要拿到 back buffer (vkAcquireNextImageKHR)，然后在渲染完毕后将其呈现（vkQueuePresentKHR），在 OpenGL 里就是类似 glClear - glfwSwapBuffers 的操作

vkPipeline 很神奇。在 OpenGL 里，你可以随时切换各种 shader 和 texture，但据教程讲，对于 Vulkan 来说，这些东西都需要被预先设置然后存到某个 pipeline 里，如果想用别的 shader 或者 texture，就必须创建新的 pipeline，如果我有几千个 shader ，就需要几千甚至上万个 pipeline！太有趣了！