Fixes in documentation regarding sparse binding.

Author: adam-sawicki-a

README.md

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

src/vk_mem_alloc.h

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