-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inefficiency in access masks #11
Comments
Hi @ShabbyX - sorry for the delay in replying - don't get much traffic over here atm! So this was 100% a deliberate design choice. In practice, drivers are already ignoring bits that don't mean anything on the basis that they have no sane meaning, and that they also aren't required to be set. So setting a READ bit in a source mask (like your example above) should really have no effect on an implementation, barring a few old drivers from before the synchronization chapter was rewritten to be actually consistent and make some sense 😅. That said, this library could act as an intermediate optimiser by nulling some more things out like this, right now this library is only acting (mostly) as a reference with a few obvious access types not being passed to the driver. I have a couple of outstanding things I'm consider doing as well in the same vein, so I'll consider doing this if I do those. NB: If you wanted to help out and provide a PR you're quite welcome, but I'd rather this be handled programmatically in the function calls instead of duplicating fields in the mapping. This could be done by detecting whether the source and destination include reads or writes, and reacting accordingly - otherwise it's just a bunch of copy pasta for access types that aren't both READ and WRITE. If you wanted to look at a PR, let me know and I'll elaborate, otherwise I'll take a look over my (non-public) todo list and see what I want to do here. |
@Tobski, that makes sense. Thanks for the explanation. I don't intend to work on this repo (or use it), though I did get inspiration from it in my own work. I just wanted to point this out, which turned out you were already aware of. |
Hey,
To be more efficient, you need to change this:
into something like this:
For example, for
THSVS_ACCESS_COLOR_ATTACHMENT_READ_WRITE
, you need to useVK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
as thedstAccessMask
when transitioning into the state, but when transitioning out, you just needVK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
forsrcAccessMask
, as WAR hazards are satisfied with execution barriers alone.(In short,
srcAccessMask
never needs a read access).The text was updated successfully, but these errors were encountered: