Inefficiency in access masks

[ShabbyX]

Hey,

To be more efficient, you need to change this:

typedef struct ThsvsVkAccessInfo {
    VkPipelineStageFlags    stageMask;
    VkAccessFlags           accessMask;
    VkImageLayout           imageLayout;
} ThsvsVkAccessInfo;

into something like this:

typedef struct ThsvsVkAccessInfo {
    VkPipelineStageFlags    stageMask;
    VkAccessFlags           dstAccessMask;
    VkAccessFlags           srcAccessMask;
    VkImageLayout           imageLayout;
} ThsvsVkAccessInfo;

For example, for THSVS_ACCESS_COLOR_ATTACHMENT_READ_WRITE, you need to use VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT as the dstAccessMask when transitioning into the state, but when transitioning out, you just need VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT for srcAccessMask, as WAR hazards are satisfied with execution barriers alone.

(In short, srcAccessMask never needs a read access).

[Tobski]

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.

[ShabbyX]

@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.