Skip to content

Resolve read-after-write hazard in api samples [hpp_]oit_linked_lists.#1510

Open
asuessenbach wants to merge 2 commits intoKhronosGroup:mainfrom
asuessenbach:oit_linked_lists
Open

Resolve read-after-write hazard in api samples [hpp_]oit_linked_lists.#1510
asuessenbach wants to merge 2 commits intoKhronosGroup:mainfrom
asuessenbach:oit_linked_lists

Conversation

@asuessenbach
Copy link
Copy Markdown
Contributor

@asuessenbach asuessenbach commented Apr 8, 2026

Description

The gather pass writes values into the fragment_buffer, while the combine pass reads from that buffer to sort the fragments.
Without the buffer barrier, that leads to a read-after-write hazard.

Build tested on Win11 with VS2022. Run tested on Win11 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

  • My code follows the coding style
  • I have reviewed file licenses
  • I have commented any added functions (in line with Doxygen)
  • I have commented any code that could be hard to understand
  • My changes do not add any new compiler warnings
  • My changes do not add any new validation layer errors or warnings
  • I have used existing framework/helper functions where possible
  • My changes do not add any regressions
  • I have tested every sample to ensure everything runs correctly
  • This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

  • I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

  • I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

  • I have tested the sample on at least one compliant Vulkan implementation
  • If the sample is vendor-specific, I have tagged it appropriately
  • I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
  • Any dependent assets have been merged and published in downstream modules
  • For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
  • For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
  • For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

@asuessenbach asuessenbach changed the title Resolve read after write hazard in api samples [hpp_]oit_linked_lists. Resolve read-after-write hazard in api samples [hpp_]oit_linked_lists. Apr 8, 2026
@asuessenbach asuessenbach requested a review from a team April 8, 2026 11:54
gary-sweet
gary-sweet previously approved these changes Apr 8, 2026
.offset = 0,
.size = vk::WholeSize};
vk::DependencyInfo dependency_info{.dependencyFlags = vk::DependencyFlagBits::eByRegion, .bufferMemoryBarrierCount = 1, .pBufferMemoryBarriers = &buffer_barrier};
command_buffer.pipelineBarrier2(dependency_info);
Copy link
Copy Markdown
Collaborator

@SaschaWillems SaschaWillems Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though this works (due to the version baseline we use), shouldn't this be pipelineBarrier2KHR instead, as the sample explicitly requests the KHR sync2 extension? If this is supposed to use the non-KHR function, then there's no need to request the sync 2 KHR extension.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

It needs to be pipelineBarrier2KHR.
And it did not work due to the version baseline we use (we're using VK_API_VERSION_1_1 by default, not VK_API_VERSION_1_3), but because the one function is an alias of the other. Both of them work with Vulkan-Hpp, as soon as either the VK_KHR_synchronization2 is enabled or VK_VERSION_1_3 is used.

-> Changed to pipelineBarrier2KHR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants