Concurrency checks are not validating subresources accesses correctly

[Cyphall]

Follow-up of the second issue reported in this message in issue #49.

I am getting a few "Potential race condition detected" between this write in the "cubemap generation" step and this read in the "mipmaps generation" step when processing an equirectangular skybox.
I think the synchronization is good but maybe I'm wrong?

Initial diagnostic:

Currently, concurrency doesn't track at a per-subresource level. So it incorrectly marks it as a race condition.

[miguel-petersen]

Dropping an update here.

I've been thinking a little bit about how to handle this in a fool-proof manner, and it's not a simple issue. Even if I was to track it on a per-subresource level, I have had (private) reports of false concurrent errors on resource writes between multiple dispatches that are guaranteed to not collide.

I think the right way forward is to track it on a per-texel/element level. There are multiple challenges here:

1. Memory usage, it will grow, and perhaps quite considerably. It's one bit per element, but that's no small amount for a whole application.
2. Bindings to memory, especially with aliasing. It's likely I'll have to handle the addressing on the underlying memory blocks (heaps in DX12, device memory on Vulkan), with the added challenge of abstracting that to the feature.
3. Compressed formats, finding some "sane" way of representing that, especially on block wise compression.
4. Sparse resources, just in general really.

And more I'm sure to come across at some point.

On the memory issue, I could keep it in host memory, but that'll be no fun for performance. Perhaps I could leave a toggle to the user.

I have some things I need to get to before I can start addressing this, but this would greatly improve both concurrency tracking and initialization tracking.

[miguel-petersen]

Just making note that I'll try addressing it this month.