gpu-alloc icon indicating copy to clipboard operation
gpu-alloc copied to clipboard

Sessioned reads and writes

Open kvark opened this issue 4 years ago • 6 comments

It would be very useful to do multiple reads/writes in a single mapping session. Currently, write_bytes and read_bytes are limited to exactly one request. Case in question: laying out texture data into the staging buffer, it needs to be done row by row to respect the alignment of the target API.

kvark avatar Nov 04 '20 17:11 kvark

In this case you can use map and unmap functions.

zakarumych avatar Nov 04 '20 21:11 zakarumych

Sure, this isn't a blocker. However, doing map/unmap manually also requires handling the flush/invalidation for non-coherent memory, which is tedious. A session-based reader/writer would strictly be better in this case.

kvark avatar Nov 04 '20 21:11 kvark

How about function that takes a closure in which reads and/or writes are available?

zakarumych avatar Nov 04 '20 21:11 zakarumych

That would be inferior to RAII. Are you concerned about safety guarantees when doing this, so that closure helps you to preserve them? I think there are no guarantees here for the most part, so no need to try restricting the users too much.

kvark avatar Nov 04 '20 21:11 kvark

I try to guarantee that memory gets unmapped. To prevent attempts to map memory when it's already mapped. Drop impls may not run, so with RAII approach it would be necessary to flip mapped field to true and then back to false in Drop impl for returned guard, along with actual unmapping. This would require &mut self function. With closure I can almost certainly guarantee unmapping to happen unless process is aborted, so mapped will be only checked and it will be &self function.

zakarumych avatar Nov 04 '20 21:11 zakarumych

Mapping is already &mut self, so I'm not sure why you are concerned about it?

kvark avatar Nov 04 '20 21:11 kvark