Fixes in documentation regarding sparse binding.

This commit is contained in:
Adam Sawicki 2018-12-11 14:54:03 +01:00
parent bc90dd54b1
commit 1db1f55db3
2 changed files with 3 additions and 7 deletions

View File

@ -42,6 +42,7 @@ Additional features:
- Customization: Predefine appropriate macros to provide your own implementation of all external facilities used by the library, from assert, mutex, and atomic, to vector and linked list.
- Support for memory mapping, reference-counted internally. Support for persistently mapped memory: Just allocate with appropriate flag and you get access to mapped pointer.
- Support for non-coherent memory. Functions that flush/invalidate memory. `nonCoherentAtomSize` is respected automatically.
- Support for sparse binding and sparse residency: Convenience functions that allocate or free multiple memory pages at once.
- Custom memory pools: Create a pool with desired parameters (e.g. fixed or limited maximum size) and allocate memory out of it.
- Linear allocator: Create a pool with linear algorithm and use it for much faster allocations and deallocations in free-at-once, stack, double stack, or ring buffer fashion.
- Support for VK_KHR_dedicated_allocation extension: Just enable it and it will be used automatically by the library.

View File

@ -1587,13 +1587,8 @@ The library uses following algorithm for allocation, in order:
Features deliberately excluded from the scope of this library:
- Support for sparse binding and sparse residency. You can still use these
features (when supported by the device) with VMA. You just need to do it
yourself. Allocate memory pages with vmaAllocateMemory().
Any explicit support for sparse binding/residency would rather
require another, higher-level library on top of VMA.
- Data transfer - issuing commands that transfer data between buffers or images, any usage of
`VkCommandBuffer` or `VkQueue` and related synchronization is responsibility of the user.
- Data transfer. Uploading (straming) and downloading data of buffers and images
between CPU and GPU memory and related synchronization is responsibility of the user.
- Allocations for imported/exported external memory. They tend to require
explicit memory type index and dedicated allocation anyway, so they don't
interact with main features of this library. Such special purpose allocations