Vulkan: динамический рендеринг изображения перехода ⇐ C++

[Anonymous]

Я перевожу свой рендерер с проходов рендеринга на динамический рендеринг и вижу сообщения проверки в Linux (точнее, Nvidia 550.78), которых я не вижу в Windows (точнее, AMD 24.3.1). Вот несколько строк, которые я отформатировал для удобства чтения:

Код: Выделить всё

[17:01:00.273][8314]: Swapchain image 0xcad092000000000d: 'ColorAttachmentOptimal'->'PresentSrcKHR'

[17:01:00.273][8314]:
Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ]
Object 0: handle = 0x555555b41130, type = VK_OBJECT_TYPE_QUEUE; |
MessageID = 0x376bc9df |
vkQueueSubmit():
Hazard WRITE_AFTER_READ for entry 0,
VkCommandBuffer 0x5555582fad00[],
Submitted access info (submitted_usage: SYNC_IMAGE_LAYOUT_TRANSITION,
command: vkCmdPipelineBarrier,
seq_no: 1,
VkImage 0xcad092000000000d[],
reset_no: 30).
Access info (prior_usage: SYNC_PRESENT_ENGINE_SYNCVAL_PRESENT_ACQUIRE_READ_SYNCVAL,
read_barriers: VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT|VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT,
,
batch_tag: 677,
vkAcquireNextImageKHR aquire_tag:677
: VkSwapchainKHR 0xe88693000000000c[],
image_index: 0
image: VkImage 0xcad092000000000d[]).

[17:01:00.273][8314]:
Validation Error: [ SYNC-HAZARD-WRITE-AFTER-WRITE ]
Object 0: handle = 0x555555b41130, type = VK_OBJECT_TYPE_QUEUE; |
MessageID = 0x5c0ec5d6 |
vkQueueSubmit():
Hazard WRITE_AFTER_WRITE for entry 0,
VkCommandBuffer 0x5555582fad00[],
Submitted access info (submitted_usage: SYNC_IMAGE_LAYOUT_TRANSITION,
command: vkCmdPipelineBarrier,
seq_no: 2,
VkImage 0x2e2941000000001f[],
reset_no: 30).
Access info (prior_usage: SYNC_LATE_FRAGMENT_TESTS_DEPTH_STENCIL_ATTACHMENT_WRITE,
write_barriers: 0,
queue: VkQueue 0x555555b41130[],
submit: 88,
batch: 0,
batch_tag: 663,
command: vkCmdEndRenderingKHR,
command_buffer: VkCommandBuffer 0x555558313000[],
seq_no: 11,
reset_no: 28).

[17:01:00.289][8314]: Swapchain image 0x967dd1000000000e: 'Undefined'->'ColorAttachmentOptimal'
[17:01:00.289][8314]: Image 0x2e2941000000001f: 'Undefined'->'DepthAttachmentOptimal'

Первая и последние две строки — это мои собственные записи, а «две средние строки» — это разбитые сообщения проверки. Похоже, что происходит какая-то ерунда с форматированием, но я сохранил недостающую информацию и был максимально последовательным в своем форматировании.
В любом случае, после того, как я отправлю командный буфер, содержащий при переходе через барьер конвейера в нем я получаю ошибку записи после чтения. Вот код, который фактически контролирует создание барьеров. Незадолго до вызова метода BeginRenderingKHR() я перемещаю буферы изображения и глубины в цепочке обмена:

Код: Выделить всё

auto &color_buffer = *Renderer::swapchain().images()[Renderer::image_index()];
color_buffer.transition_layout(Renderer::cmd_buffer(),
vk::ImageLayout::eUndefined,
vk::ImageLayout::eColorAttachmentOptimal);

_depth_buffer.transition_layout(Renderer::cmd_buffer(),
vk::ImageLayout::eUndefined,
vk::ImageLayout::eDepthAttachmentOptimal);

Затем, сразу после вызова endRenderingKHR(), я перемещаю буфер цвета:

Код: Выделить всё

auto &color_buffer = *Renderer::swapchain().images()[Renderer::image_index()];
color_buffer.transition_layout(Renderer::cmd_buffer(),
vk::ImageLayout::eColorAttachmentOptimal,
vk::ImageLayout::ePresentSrcKHR);

А вот код перехода изображения (

Код: Выделить всё

vkSwapchainImage

не применяется к буферу глубины, но логика та же):

Код: Выделить всё

void vkSwapchainImage::transition_layout(vkCmdBuffer const &cmd_buffer,
vk::ImageLayout const old_layout,
vk::ImageLayout const new_layout)
{
BTX_TRACE("Swapchain image {}: '{:s}'->'{:s}'",
_handle,
vk::to_string(old_layout),
vk::to_string(new_layout));

vk::ImageMemoryBarrier barrier {
.srcAccessMask = { },
.dstAccessMask = { },
.oldLayout = old_layout,
.newLayout = new_layout,
.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
.image = _handle,
.subresourceRange {
.aspectMask     = vk::ImageAspectFlagBits::eColor,
.baseMipLevel   = 0u,
.levelCount     = 1u,
.baseArrayLayer = 0u,
.layerCount     = 1u,
}
};

vk::PipelineStageFlags src_stage = vk::PipelineStageFlagBits::eNone;
vk::PipelineStageFlags dst_stage = vk::PipelineStageFlagBits::eNone;

if(old_layout == vk::ImageLayout::eUndefined) {
barrier.srcAccessMask = vk::AccessFlagBits::eNone;

if(new_layout == vk::ImageLayout::eColorAttachmentOptimal) {
barrier.dstAccessMask = vk::AccessFlagBits::eColorAttachmentRead
| vk::AccessFlagBits::eColorAttachmentWrite;

src_stage = vk::PipelineStageFlagBits::eTopOfPipe;
dst_stage = vk::PipelineStageFlagBits::eColorAttachmentOutput;
}
else if(new_layout == vk::ImageLayout::eDepthAttachmentOptimal) {
barrier.dstAccessMask =
vk::AccessFlagBits::eDepthStencilAttachmentRead
| vk::AccessFlagBits::eDepthStencilAttachmentWrite;

src_stage = vk::PipelineStageFlagBits::eTopOfPipe;
dst_stage = vk::PipelineStageFlagBits::eEarlyFragmentTests
| vk::PipelineStageFlagBits::eLateFragmentTests;
}
else {
BTX_CRITICAL("Unsupported image layout transition");
return;
}
}
else if(old_layout == vk::ImageLayout::eColorAttachmentOptimal) {
barrier.srcAccessMask = vk::AccessFlagBits::eColorAttachmentRead
| vk::AccessFlagBits::eColorAttachmentWrite;

barrier.dstAccessMask = vk::AccessFlagBits::eNone;

src_stage = vk::PipelineStageFlagBits::eColorAttachmentOutput;
dst_stage = vk::PipelineStageFlagBits::eBottomOfPipe;
}
else {
BTX_CRITICAL("Unsupported image layout transition");
return;
}

cmd_buffer.native().pipelineBarrier(
src_stage,  // Source stage
dst_stage,  // Destination stage
{ },        // Dependency flags
nullptr,    // Memory barriers
nullptr,    // Buffer memory barriers
{ barrier } // Image memory barriers
);

_layout = barrier.newLayout;
}

Я постарался скопировать переходы изображений точно из официального примера кода динамического рендеринга, и они кажутся нормальными в Windows/AMD, но, конечно, я хотел бы понять, что является неполным или что-то не так.
И, конечно, любые структурные улучшения для лучшей обработки переходов изображений будут очень приветствоваться. =)

Подробнее здесь: https://stackoverflow.com/questions/784 ... transition