Possible handling of mapped memory

[olivia-fl]

Vulkan doesn't allow mapping the same memory object multiple times. This is somewhat of an issue for the way I'm currently using this library, since I have a library which allocates from a SmartAllocator and then maps the resulting memory in order to update buffers every frame. The problem is that I have no way to know that whatever program is calling the library function doesn't end up with a Block from the same memory object and also want to map that. I think the correct way to go about this would be to have some layer in between which handles mapping so that it would re-map the memory object to cover the range of both blocks if somebody tries to map two Blocks.

I'm currently thinking about just creating a separate SmartAllocator instance inside my library's struct, and then handling mapping by hand. This still isn't simple though, because I have two separate buffers. I would need to make sure that if both buffers refer to the same memory object that it gets mapped once, but if the refer to different objects, that each of them is mapped.

I'm not really sure if this type of thing is in scope for what gfx-memory is trying to do, but I think there should be a layer at some point to help with re-usability.

[zakarumych]

@Benjamin-L FWIW there is another crate which handles mapping for you.
It will make few gfx-* crates obsolete though when ready.

IIRC webgpu-rs already switched to it from gfx-memory.
If you consider using it then check for this branch as it will be merged soon.