Synchronisation simplification/overhaul based on vk-sync-rs #6
Conversation
|
Thanks for taking time making this. This looks interesting. I'll find time to review it thoroughly asap. |
| VertexShaderReadUniformBuffer, | ||
|
|
||
| /// Read as a sampled image/uniform texel buffer in a vertex shader | ||
| VertexShaderReadSampledImageOrUniformTexelBuffer, |
|
|
||
| /// Defines all potential resource usages | ||
| #[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)] | ||
| pub enum Access { |
There was a problem hiding this comment.
Does this enumeration contain all valid combinations of access type and stage?
If not, could it become a problem?
| pub new_layout: Layout, | ||
| pub prev_access: Access, | ||
| pub next_access: Access, | ||
| pub old_layout: Option<SyncLayout>, |
There was a problem hiding this comment.
Here None would mean UNDEFINED. i.e. the Manual variant
| pub old_layout: Option<Layout>, | ||
| pub new_access: AccessFlags, | ||
| pub new_layout: Layout, | ||
| pub prev_access: Access, |
There was a problem hiding this comment.
What if multiple read accesses were performed before?
| pub new_access: AccessFlags, | ||
| pub new_layout: Layout, | ||
| pub prev_access: Access, | ||
| pub next_access: Access, |
There was a problem hiding this comment.
What if multiple read accesses are planned?
| pub prev_access: Access, | ||
| pub next_access: Access, | ||
| pub old_layout: Option<SyncLayout>, | ||
| pub new_layout: SyncLayout, |
There was a problem hiding this comment.
Instead of using SyncLayout we could offer calculation of optimal Layout in methods that build this type.
| #[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)] | ||
| pub struct BufferMemoryBarrier<'a> { | ||
| pub buffer: &'a Buffer, | ||
| pub offset: u64, | ||
| pub size: u64, | ||
| pub old_access: AccessFlags, | ||
| pub new_access: AccessFlags, | ||
| pub prev_access: Access, |
There was a problem hiding this comment.
What if multiple read accesses were performed before?
| pub old_access: AccessFlags, | ||
| pub new_access: AccessFlags, | ||
| pub prev_access: Access, | ||
| pub next_access: Access, |
There was a problem hiding this comment.
What if multiple read accesses are planned?
|
It would be blast if both old flags-based and new approach would be available for the user. |
I think this fits with the ethos of
sierrain simplifying Vulkan concepts while still remaining as flexible/usable as possible. We've been using similar sort of sync primitives at Embark for a little while now and it's been working quite well and feels nice. I know this is a pretty large change so feel free to give feedback or just say if it doesn't fit in your vision for the lib.