Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Support VK_KHR_synchronization2 in the API #3670

Open
kvark opened this issue Mar 12, 2021 · 1 comment
Open

Support VK_KHR_synchronization2 in the API #3670

kvark opened this issue Mar 12, 2021 · 1 comment

Comments

@kvark
Copy link
Member

kvark commented Mar 12, 2021

See https://gpuopen.com/vulkan-sync2-support/ and https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_synchronization2.html

One of the important bits of difference is that both sides of an event/barrier now know about the barrier contents. This matches DX12 split barriers, so there is an obvious benefit here.

I think what we should do is having this extra information optional in set_event. If the user provides it, then the backend can take advantage of a split barrier. Otherwise, it's the same as today. Vulkan Portability would be using the old version for a while.

@kvark
Copy link
Member Author

kvark commented Apr 15, 2021

This appears to be more problematic than I thought. The wait_events are supposed to receive a list of the sets of barriers now, as opposed to the just a set of barriers for all the events at once.
Moreover, each individual barrier now carries its own stage mask.
This probably needs a bit more thought, doesn't need to block hal-0.8.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant