问题[vulkan](coding)

SPIR-V 规范为操作、和定义了一个可选的打包向量格式开关。使用时，该操作的另外两个输入必须分别为 32 位整数，然后将其解释为 8 位整数的打包 4 维向量。OpSDotOpUDotOpSUDot

我的问题

在“打包矢量格式”情况下，这些标量 32 位整数参数的符号是​​否必须与其 8 位分量的（逻辑）符号匹配，或者打包的 32 位标量是否必须是无符号的（例如，在 WGSL 中的情况）？

我为什么对此感到困惑

和的规范OpSDot仅OpUDot规定“向量 1 和向量 2 必须具有相同的类型”，并且它们“必须是 32 位整数 [...] 或向量”，但并未明确规定它们是否必须带符号。如果它们是（未打包的）向量，那么在我看来，显然 和OpSDot期望 是带符号向量，而OpUDot和 期望 是无符号向量。但是，当将四个带符号的 8 位整数打包成一个 32 位标量时，我认为将结果视为无符号整数（就像在 WGSL 中一样）更为自然，因为此时，它只是一个“位的集合”，标准算术运算对它来说毫无意义。

使用 进行验证spirv-val似乎无论如何都可以接受，但它甚至接受带有符号的32 位整数输入，用于与进行无符号打包点积OpUDot，这在我看来很奇怪，所以我不信任这里的验证器。更让我困惑的是， （执行混合有符号/无符号整数点积）的规范OpSUDot确实明确指出第二个参数必须是无符号的，但它限定这仅适用于两个参数都是（解包）向量的情况：

[...]当向量 1 和向量 2 为向量时，向量 2 的分量的符号性必须为 0。[← 如果输入为（解包）向量，则定义符号性]

当向量 1 和向量 2 为标量整数类型时，必须指定打包向量格式来选择如何将整数解释为向量。[← 参数为“标量整数类型”（即打包）的情况将另行讨论，无需指定符号]

（重点和注释由我[...] 撰写。）

当我在调用 vkGetPhysicalDeviceFeatures 时给出要填写的扩展结构的指针时，rayTracingPipeline 标志为 1，这意味着它应该被支持，并且 VkPhysicalDeviceRayTracingPipelineFeaturesKHR 中的所有标志都设置为 1。但是，当我创建逻辑设备时，出现验证错误：

pCreateInfo->pNext 包含指向 VkPhysicalDeviceRayTracingPipelineFeaturesKHR 的指针，但是在创建 VkDevice 时，父扩展（VK_KHR_ray_tracing_pipeline）未包含在 ppEnabledExtensionNames 中。

公平地说，听起来我必须在创建逻辑设备时在启用的扩展列表中启用 VK_KHR_RAY_TRACING_PIPELINE_EXTENSION_NAME。所以我这样做了，但结果却出现了：

Vulkan 验证层回调：loader_validate_device_extensions：所选物理设备或启用的层不支持设备扩展 VK_KHR_ray_tracing_pipeline。

Vulkan 验证层回调：vkCreateDevice：无法验证列表中的扩展

当我使用 vkEnumerateDeviceExtensionProperties 检查扩展名时，它不在列表中。我正在使用 Radeon RX570。

据我了解，VkVertexInputBindingDescription stride 是顶点缓冲区元素块的大小，而 vkCmdBindVertexBuffers offset 是与顶点缓冲区元素块的偏移量。

vkCmdBindVertexBuffers 偏移量不能超过 VkVertexInputBindingDescription 步幅大小。

我检查了WebGPU和DX12图形API，API步幅和偏移大小相同。

Vulkan 是否遗漏了什么？或者我遗漏了什么？

我正在一台集成显卡的笔记本电脑上开发一款 Vulkan 应用（只有一个 VkQueue），启动时我需要运行一个非常昂贵的片段着色器，其输出稍后会被读取为纹理。问题是，如果耗时太长，操作系统（我相信）有时会将其杀死，从而导致 VK_ERROR_DEVICE_LOST。

为了解决这个问题，我分解了渲染工作，将绘制调用细分为不同的剪刀/渲染区域，每个剪刀/渲染区域都有自己的命令缓冲区和 VkSubmitInfo，即共享帧缓冲区。这已经修复了设备丢失错误，但是除了最后一个剪刀外，所有剪刀上都有噪音/垃圾。它不是完全随机的：可以看到已经进行了绘制，但似乎驱动程序认为在完成剪刀的渲染后内存可供使用。

我需要告诉驱动程序“不要触碰这块内存”，我认为这是帧缓冲区渲染区域的要点。

如果我将附件的 initialLayout 设置为 READ_ONLY_OPTIMAL（与 finalLayout 相同）而不是 UNDEFINED，则一切正常，但当然我会收到验证错误，提示图像的布局错误。尝试将图像转换为正确的布局会再次中断渲染。

因此，我认为我错误地设置了管道屏障：

VkImageMemoryBarrier barrier = {
        .sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER,
        .image = image,
        .oldLayout = VK_IMAGE_LAYOUT_UNDEFINED,
        .newLayout = VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL,
        .srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
        .dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
        .subresourceRange.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT,
        .subresourceRange.levelCount = 1,
        .subresourceRange.layerCount = 1,
    };
}
vkCmdPipelineBarrier(cmd[i],
                     VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
                     VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
                     0, // dependencyFlags
                     0, NULL, 0, NULL, 1, &barrier);

我做错了什么？

解决方案：

renderpass = {.initialLayout=COLOR_ATTACHMENT, .finalLayout=.initialLayout}
if batch == 0
    vkCmdPipelineBarrier(TOP_OF_PIPE, COLOR_ATTACHMENT_OUTPUT,
        barrier={.oldLayout=UNDEFINED, .newLayout=COLOR_ATTACHMENT})

renderpass begin, ..., renderpass end

if batch == last
    vkCmdPipelineBarrier(COLOR_ATTACHMENT_OUTPUT, COLOR_ATTACHMENT_OUTPUT,
        barrier={.oldLayout=COLOR_ATTACHMENT, .newLayout=READ_ONLY})

当 GPU 使用同一缓冲区作为传输操作的源时，让 CPU 从缓冲区读取数据是否安全vkCmdCopyBuffer？

我之所以问这个问题，是因为我读到过，即使缓冲区用作传输源，其vkCmdCopyBuffer本身也可能比简单的 GPU 读取更复杂，因此需要显式主机同步（即：复制必须先完成，CPU 才能从缓冲区读取）。但我找不到任何可以证实这一点的证据。

我在 Vulkan 中有一个带有colorBlendState、blendEnable = false、的管道logicOpEnable = true，logicOp = XOR以便片段着色器的输出与颜色附件的当前内容进行异或。我有这个工作，它的行为符合预期......大部分。

问题是，当在片段缓冲区中使用重叠三角形时，即使它们都位于同一渲染通道中，这些三角形似乎也会相互异或。经过一番研究后，这似乎可能是正确的行为，但这不是我的案例所期望的。有什么方法可以修改我的管道/渲染通道以仅在片段着色器输出和加载的颜色附件内容之间执行逻辑操作，而不是在片段着色器的各个三角形之间执行逻辑操作？

也就是说，我希望在没有混合或逻辑操作的情况下绘制顶点缓冲区中定义的所有三角形，直到最终结果写入颜色附件。有没有办法在不添加第二个渲染通道或子通道的情况下做到这一点？

Vulkan子组教程提到：

如果您指定的工作组大小小于子组大小，则保证子组内有非活动调用。

现在假设您的 maxComputeWorkGroupSize为1024，subGroupSize为 64。如果您想对图像应用过滤器，您可能会进行 2D 调用。因此，您最终的工作组大小将为 32，因为 32 * 32 * 1 = 1024。现在您的工作组大小小于子组大小。

所以我的问题是，是否最好使用 64 的 1D 工作组大小（并从现在“更大”的 GlobalInitationID.x 中提取相应的 x 和 y 坐标）？

我有两个队列，队列 A 和队列 B，来自不同的队列系列。队列A当前拥有独占共享模式的镜像所有权。我想提前将图像的所有权释放给队列B，因为我知道它将是下一个使用它的人。但是，我不知道布局队列 B 是否需要图像。

问题是释放屏障（在队列 A 上）和获取屏障（在队列 B 上）都需要指定源图像布局和目标图像布局。在事先不知道布局的情况下，如何将图像发布到队列B？

我认为最好的方法是在记录到队列 B 时使用两个图像内存屏障：第一个从队列 A 获取图像（不更改布局），第二个执行布局转换。问题是我不知道如何创建依赖项以确保获取图像后发生布局转换。有没有办法在两个连续图像内存屏障之间创建这种依赖关系？