关于Vulkan的Descriptor Pool设计

[sanseiuP]

最近看到描述符相关内容，有个疑问。如果我的Vulkan程序无法预先知道描述符的使用情况（比如存在一些运行时着色器的动态编译），我应该咋设计Descriptor Pool。
一个简单的想法是先创建一个容量很大的Descriptor Pool，分配不够了就再创建一个，构成Descriptor Pool数组。但是这样做似乎存在木桶效应，因为一个Descriptor Pool中只要某个描述符资源不够，就会导致描述符集分配不出来。池里明明还有描述符却无法充分使用，感觉效率不高。
然后今天看了下Godot的实现，它的策略是每个Descriptor Pool对应一种描述符集Layout。当出现一种新的Layout（或现有描述符池满了）时，创建对应的Descriptor Pool，并使其中包含足以分配64个描述符集的资源。这样可以避免之前提到的木桶效应。
但是感觉也不是很完美，如果某种Layout只分配一个描述符集，就有63倍的资源是浪费的。而且Descriptor Pool的数量很多，池化效率不太高的样子。。。

[EasyVulkan]

我有点不太清楚该从什么角度回答这个问题。
大致感觉这个问题可以从两个方面思考：

1. 如果不知道某种描述符有多少，如何避免让描述符池分配多余的描述符。
2. 或者，如何预测各种类描述符的使用频率。

每个Descriptor Pool对应一种描述符集Layout

个人认为这个做法合理，不过一开始不必分配很大的描述符池，可以用类似std::vector的扩容规则的方式封装。
需要扩容的时候，将描述符从旧的描述符拷贝到新描述符（填写VkCopyDescriptorSet），然后再销毁旧的池子。这么封装的话，需要注意避免悬垂handle。

需求不至于过分宽泛的话，可以试着预测描述符的使用频率。
每个管线，你有4套描述符集可用（我不知道移动端是不是这样，桌面端设备一般是4套），即一个管线布局可以有4个不同的描述符集布局。
怎么利用这4套描述符集，根据具体需求，会有不同的想法，比如：
假设你要实现一个可以让用户可以定制（比如图形化编程）的渲染管线，哪怕这个管线的功能很灵活，大致也可以把描述符合理分为四个部分：世界空间参数（投影、观察矩阵等）、物体参数（平移旋转放缩等）、物体材质、场景参数。
前两个set应该都是一堆buffer，物体材质应该大都是贴图，场景参数可能有光源信息存在buffer中，可能有光照贴图和阴影贴图。
这么一来，对于各种类型的描述符在各个描述符集中的出现频率会有个大致预期，描述符池应该怎么分配也就会有个大致预期（贴图一般肯定是用的最多的）。

前面的都是废话

其实可以直接不使用descriptor pool，使用descriptor buffer来手动管理描述符的底层数据。
但是VK_EXT_descriptor_buffer还未进入核心功能，且硬件未必支持，比如intel核显就不支持。
关于descriptor buffer，你可以看Khronos的这篇文章：https://www.khronos.org/blog/vk-ext-descriptor-buffer
顺带一提，这篇文章里还提到了descriptor indexing，这个做法可以避免创建新layout，但不节省描述符池的容量。

[sanseiuP]

原来如此，我忽略了描述符可以拷贝，那么按照std::vector的方式扩容确实利用率会更高。而且我也忽略了一个管线布局可以绑定多个描述符集，也就是说我不必在一个描述符集中分配所有类型的资源，描述符池自然也不必包含所有类型的资源，资源比例的预测相对就比较容易了。
感谢解答。