渲染调用性能消耗答案

【问题标题】：Render-call performance drain渲染调用性能消耗
【发布时间】：2016-05-15 14:37:28
【问题描述】：

我的 Vulkan 程序运行非常缓慢，我正在尝试找出原因。我注意到，即使是一些绘制调用也已经消耗了远远超过应有的性能。例如，这是一个用于渲染一些网格的提取（伪代码）：

int32_t numCalls = 0;
int32_t numIndices = 0;
for(auto &mesh : meshes)
{
    auto vertexBuffer = mesh.GetVertexBuffer();
    auto indexBuffer = mesh.GetIndexBuffer();

    vk::DeviceSize offset = 0;
    drawCmd.bindVertexBuffers(0,1,&vertexBuffer,&offset); // drawCmd = CommandBuffer for all drawing commands (single thread)
    drawCmd.bindIndexBuffer(indexBuffer,offset,vk::IndexType::eUint16);

    drawCmd.drawIndexed(mesh.GetIndexCount(),1,0,0,0);

    numIndices += mesh.GetIndexCount();
    ++numCalls;
}

有 238 个网格被渲染，总顶点索引计数为 52050。GPU 绝对不会负担过重（着色器非常便宜）。

如果我使用上面的代码运行我的程序，帧将在大约 46 毫秒 内呈现。没有它，它只有 9ms。

我正在使用带有 2 个交换链图像的 fifo 呈现模式。此时只有一个主命令缓冲区（没有辅助命令缓冲区/预先记录的缓冲区），所有帧都使用相同的缓冲区。

我的问题是，我真的不知道要寻找什么。这几个渲染调用应该几乎没有影响，所以问题的根源一定在其他地方。

谁能给我任何提示我应该如何解决这个问题？是否已经有 Vulkan 的分析器？我只需要朝着正确的方向轻推。

// 编辑：

因此，如果所有 238 个网格都被渲染，看起来 vkDeviceWaitIdle 需要大约 32 毫秒来执行。（如果没有渲染，则小于 1 毫秒）。大部分的停滞都源于那里，但我仍然不知道该怎么办。

【问题讨论】：

auto vertexBuffer = mesh.GetVertexBuffer(); 这会导致复制可能成为瓶颈。
不是，是句柄（8 字节）。索引缓冲区也是如此。实际的cpp-code对帧时间基本没有影响。
vkDeviceWaitIdle 你打电话是为了什么？这就像glFinish;这是你应该永远不要做的事情。除非您正在进行主要的应用程序状态转换（甚至可能不会）或应用程序拆除。
听起来像 vkDeviceWaitIdle 是您的主要问题，但您是否启用了验证层？使用 VK_LAYER_LUNARG_standard_validation 会增加大量开销。

标签： c++ performance rendering vulkan

【解决方案1】：

因此，如果所有 238 个网格都被渲染，看起来 vkDeviceWaitIdle 需要大约 32 毫秒来执行。（如果没有渲染，则小于 1 毫秒）。大部分的停滞都源于那里，但我仍然不知道该怎么办。

避免使用 vkDeviceWaitIdle。这是可用的最繁重的同步操作，将强制 GPU 完成并刷新所有工作。

尝试使用其他更轻量级的同步对象，如信号量、屏障、栅栏和事件，并指定范围尽可能窄的访问掩码和管道阶段。

一个狭窄的范围，特别是对于管道阶段，确保管道的其他部分可以继续工作，而使用 vkDeviceWatiIdle 您可能会停止管道的所有部分。

【讨论】：

我从教程中了解到，vkDeviceWaitIdle 用于程序终止，然后再销毁 vulkan 实例。它一直等到 GPU 完成所有操作，这样您就可以安全地销毁所有 vulkan 对象。

【解决方案2】：

绝对没有理由在渲染循环中使用vkDeviceWaitIdle。

相反，您应该在 vkQueueSubmit 调用中添加一个 vkFence 并使用 vkGetFenceStatus 来查看您是否可以触摸命令缓冲区使用的内存。

这将像环形缓冲区一样使用，因此存储可变数据（视图矩阵等）的多个副本，直到 GPU 处理完它们。

【讨论】：