渲染有时需要不同着色器配置的多种不同材质

Question

我正在尝试构建一个基于 3D 体素的游戏引擎来学习如何使用 vulkan。我撞到了一堵墙，我找不到有关如何攀登的文档。现在我正在绘制一个 2D 三角形并在屏幕上移动它，我的 2D 三角形被定义为顶点缓冲区中的 1 个顶点，将来会在我的顶点着色器中转换为屏幕空间。这个单个顶点被我的几何着色器变成了 3 个顶点，然后传递给我的片段着色器。

    triangle_center_position[0] = (cursor_x - (vulkan_window_width_get() / 2.0f)) / vulkan_window_width_get();
    triangle_center_position[1] = (cursor_y - (vulkan_window_height_get() / 2.0f)) / vulkan_window_height_get();
    // send to gpu via memory mapped region
    memcpy(triangle_position_buffer.mapped_memory, &triangle_center_position, sizeof(vec2) * 1);

它以下列方式绑定在命令缓冲区中：

    VkBuffer vertexBuffers[] = {buffer->buffer};
    VkDeviceSize offsets[] = {0};
    vkCmdBindVertexBuffers(command_buffer[i], 0, 1, vertexBuffers, offsets);
    vkCmdDraw(command_buffer[i], (uint32_t) buffer->num_elements, 1, 0, 0);

我的计划是最终修改此代码以接收 3D 点，并让我的几何着色器将我的 3D 点扩展为体素。

不幸的是，我只希望这种转换发生在体素世界中的块上，而不是其他事物（玩家模型等）上。

在 OpenGL 中，我只会调用glUseProgram()为不同的“材质”构建的两个着色器程序，这在 vulkan 中似乎非常不鼓励。我的直觉是这样的

currentMaterial = null
for (Renderable r : sort(everything, by material type)) 
    if (!r.isWithinViewOfScreen()) 
        continue
    if (r.material != currentMaterial)
        currentMaterial = r.material
        r.material.use()
    r.render()

主要问题是某些Renderables 将使用完全不同的着色器要求，但 vulkan 中似乎没有规定在着色器程序之间进行交换。

Answer 1

vulkan 中似乎没有规定在着色器程序之间进行交换。

与glUseProgramvulkan 中最接近的类似物是vkCmdBindPipeline.

主要区别在于大部分被认为是 OpenGL 状态机的一部分都被烘焙到 Vulkan 管道对象中。因此，例如，在 OpenGL 上，您可能会调用glUseProgram、渲染一些内容，然后调用glDisable(GL_DEPTH_TEST)并渲染更多内容，而在 Vulkan 上，这些将是两个不同的管道，并且vkCmdBindPipeline每个都需要调用。

如果您熟悉vkCmdBindPipeline并且正在寻找某种方法来修改哪些着色器，那么简短的回答是您不能这样做。您需要为您需要使用的每组着色器创建一个完整的 VkPipeline 对象，即使管道中的其他值都没有不同。

但是，如果您担心最终会创建大量管道并且这会影响您的性能，您应该考虑使用管道缓存和 VK_PIPELINE_CREATE_DERIVATIVE_BIT 标志，它允许您创建类似 child 的东西来自模板管道的管道。这应该会产生与您从 OpenGL 获得的相同或更好的性能。

编辑：

记住，开发商试图提高管道创作上的表现应该用这两个的VkPipelineCache功能以及VK_PIPELINE_CREATE_DERIVATIVE_BIT。派生管道对您有多大帮助完全取决于驱动程序，并且某些驱动程序（如ARM MALI驱动程序）被明确记录为忽略此标志。Vulkan 规范没有就何时使用或不使用派生标志提供任何指导。正确的方法可能是直接与 ISV 合作以找出如何最好地应用它，或者始终使用它，希望它能在可能的情况下提高性能而不影响性能，或者根本不使用衍生产品.

另一方面，管道缓存功能几乎肯定会缩短各种硬件上的管道创建时间。