在Vulkan中，我理解描述符池用于分配某些布局的描述符集以在着色器中使用，但在传递给VkDescriptorPoolCreateInfo的{{1}}中，有一个字段{{1它包含一堆包含描述符类型和数字的对象。
文档似乎有点模糊，但这是说给定的描述符池只能在描述符集中从它分配的每种类型的描述符中有一定的预定量吗？如果是这样，我如何确定预先需要多少？如果它耗尽会怎样？
答案 0 :(得分：3)
您对描述符池的理解是正确的。
如果是这样，我如何确定预先需要多少？
这取决于您和您的应用程序的需求。
如果您的应用程序需要完全灵活且自由格式化，那么您将需要根据需要动态创建描述符池。如果您的应用程序对场景的外观有更多预知，那么您的应用程序将需要更少的此类体操。
许多严重的Vulkan应用程序试图避免让描述符集的数量基于场景中的对象数量。推送常量和/或动态UBO / SSBO描述符允许使用不同的每对象状态而不更改描述符本身。许多对象的纹理可以捆绑在一起成为数组纹理，或者根据硬件，纹理数组。
在一个完美的世界中，类型的所有网格（比如，蒙皮网格）都可以使用完全相同的描述符集进行渲染，使用一些每对象状态来获取正确的矩阵/纹理数据对于那个对象。
但这就是他们的呈现方式。这些应用程序可以严格控制它们呈现的对象类型，每个对象数据的外观等等。其他应用程序可能有不同的需求。
Vulkan是一种工具;你如何使用它完全取决于你。
如果用完了怎么办？
然后您无法从该池中分配更多描述符。如果需要分配另一个描述符集，则需要创建另一个池。
答案 1 :(得分：0)
我的方法是让一个类最初分配描述符的N，如果它用完了，它将创建另一个具有N * 2个条目的池。它的尺寸会增加一倍。它使用一个简单的链接列表，当涉及分配时，它只是尝试第一个，如果它已满，则移动到下一个。
这一切都非常低效，所以如果必须创建第二个池，我也会让我的代码触发一个断言，这样我就可以确保选择N的值足够大因此，零售版本永远不应该这样做（但如果由于一些无法预料的情况，它会以某种方式设法，它仍会正确呈现）。
当时，我记得诅咒规范并希望描述符池会像命令池一样自动增长。我仍然想象他们就像他们一样。