Clarification on GPU-CPU Buffer Access

[killer-of-Plato]

Hi everyone,

I have a need for frequent high-performance transmission of consistently sized data from the GPU to the CPU. From my understanding, this process involves repeatedly mapping and unmapping intermediate buffers.

I am curious if there is a technical constraint that prevents simultaneous GPU and CPU access to a mapped buffer, assuming competent synchronization is in place. Is this limitation primarily a safeguard against potential issues (foot-gunning), or are there deeper technical reasons behind this restriction?

Thank you for your insights!

[teoxoy]

Is this limitation primarily a safeguard against potential issues (foot-gunning), or are there deeper technical reasons behind this restriction?

As far as I know this is the main reason. The native APIs support persistent mapping so we could update our implementation to internally no-op unmap calls but this would have to be driven by some perf numbers showing that unmap (but excluding flush) is expensive.

[teoxoy]

We can still do this optimization internally. If the 2nd call to map has the same range as the previous one, do nothing, if it's different, unmap then map again. I think we still need perf numbers showing that it would be faster to land a PR doing this.

[killer-of-Plato]

I am unsure if I would be able to provide meaningful data as I assume the flush you mention is not currently accessible for comparison.

[teoxoy]

This would require implementing the internal changes and then benchmarking.

It doesn't seem terribly complicated to make the changes, I can give it a shot. That is if you'd be up for a PR adding the benchmarks first.

[cwfitzgerald]

Imo this doesn't need benchmarks, as it'll actually make the internals simpler, not more complicated

[teoxoy]

It will make internals simpler but the calls won't be as straight-forward as they are now.