Comments (4)
First of all, thank you for your question and deep analysis of the problem. Discussions like this help to improve quality of the library.
Regarding your first question: Yes, this is correct. vmaMapMemory is synchronized internally in the way that it is safe to call it on different VmaAllocation objects that have the same VkDeviceMemory from different threads.
Regarding your last question: No, setting preferredLargeHeapBlockSize doesn't mean such block size is guaranteed. Some blocks may be allocated as smaller or larger, depending on internal library heuristics. More specifically, first blocks are smaller not to allocate such large block if you actually use only little memory from certain type.
That said, I must admit that the library here has some room for improvement in the subject discussed here. Please feel free to propose improvements to the library that you would like to see. I'm willing to work on this and release a new version that will support non-coherent memory better. First ideas that come to my mind are:
-
For each memory type that is HOST_VISIBLE but not HOST_COHERENT, allocations would be automatically aligned to nonCoherentAtomSize and always lie on separate pages of this size. Block size would also always be multiple of nonCoherentAtomSize.
-
Convenience functions could be added to support Flush and Invalidate, like:
void vmaFlushAllocation(VmaAllocation allocation, VkDeviceSize offset, VkDeviceSize size);
void vmaInvalidateAllocation(VmaAllocation allocation, VkDeviceSize offset, VkDeviceSize size);
In the meantime, you can just #define VMA_DEBUG_ALIGNMENT 256
. If your preferredLargeHeapBlockSize is a multiply of 2 MB (by default it is), you can be sure that size of allocated block is also a multiply of 256 (as long as it's not a dedicated allocation) - which is the largest nonCoherentAtomSize found in the wild now, according to http://vulkan.gpuinfo.org/listlimits.php. You should be safe then.
from vulkanmemoryallocator.
Thanks for the response and the suggestion for the current way to workaround the issue.
For our current library we went with an approach which is basically like option 1. that you suggested above. It's the easier one to implement as you just need to update the alignment when you're allocating the block. However, it does mean you end up with less flexibility in how you sub-allocate and you can end up with more wasted space.
Option 2 is nice in that it shouldn't effect the allocation/sub-allocation schemes at all, and works as long as the offset and size passed in are within the individual VmaAllocation (easy enough to assert/check). The library should then have enough knowledge to know how to pad the beginning and ends to make sure it is aligned with nonCoherentAtomSize. This approach does require that you are always mapping the entire the VkDeviceMemory incase the padding enters into other VmaAllocations. This is what the library currently does so it should be fine, but if there is any future plans to not map the entire VkDeviceMemory this will then have to be taken into consideration.
Option2 does mean that the library will need to do some additional work each time flush or invalidate is called to calculate the padding. However, this is work that the client would/should be doing otherwise so it shouldn't add any more work in total, excluding the scenario where we used option 1 and only sub-allocations got mapped and the client always flushed/invalidated the entire mapping (thus no need for checking alignments).
Anyways given the current library, I think option 2 would be the better, most flexible approach.
from vulkanmemoryallocator.
I didn't mean either 1 or 2 as alternative options, but rather both. I'm sorry if that wasn't clear enough.
I think that aligning allocations to nonCoherentAtomSize always is right thing to do. Even the worst case of 256B it's still just 16*vec4. I think that such alignment wouldn't result in too much wasted space, as using large number of buffers smaller than that doesn't sound like a good practice anyway.
As you noticed, the library always maps entire VkDeviceMemory object. There are no plans to change that.
from vulkanmemoryallocator.
@egdaniel I'm sorry for the delay. I pushed major update with support for non-coherent memory to "development" branch, as I described above. Can you please check if it works and looks good to you?
from vulkanmemoryallocator.
Related Issues (20)
- missing VMA_LEN_IF_NOT_NULL in vmaCopyMemoryToAllocation/vmaCopyAllocationToMemory HOT 1
- Buggy mapping hysteresis optimization HOT 2
- Asserts on Android 9 wth vkGetPhysicalDeviceMemoryProperties2KHR HOT 2
- no support for `VkBufferUsageFlags2CreateInfoKHR` HOT 2
- Specify in documentation that individual pools can be individually used w/o external synchronization HOT 1
- Compatibility issue with Vulkan 1.2.198 on OSX HOT 3
- Can I batch all allocations in one function call to VMA if I know my memory requirements upfront? HOT 2
- Building VulkanMemoryAllocator for C HOT 2
- Changes to PFN_vmaAllocateDeviceMemoryFunction HOT 1
- do not create a dummy buffer and destroy when call vmaFindMemoryTypeIndexForBufferInfo HOT 2
- Validation layer error in sample application HOT 5
- Problem when running tests of sample application on NVIDIA RTX 3090 HOT 5
- Use vkSetDebugUtilsObjectNameEXT to make debugging easier
- Question about 'Advanced data uploading' in the docs HOT 5
- C++20 module HOT 1
- VmaAllocator_T::Map illegal use of [[fallthough]] HOT 1
- Remove unused BasicTestBuddyAllocator()? HOT 3
- Write a new test which covers 'advanced data uploading' from docs HOT 5
- Clarify docs and improve pool API thread-safety guarantees if possible HOT 2
- Introduce a CMake option which allows VMA_DEBUG_LOG to be enabled easily HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vulkanmemoryallocator.