Skip to content
This repository has been archived by the owner on Sep 21, 2023. It is now read-only.

Possible handling of mapped memory #20

Open
Benjamin-L opened this issue Nov 17, 2018 · 1 comment
Open

Possible handling of mapped memory #20

Benjamin-L opened this issue Nov 17, 2018 · 1 comment

Comments

@Benjamin-L
Copy link

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
Copy link

zakarumych commented Nov 17, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
2 participants