Function vk_mem_alloc::ffi::vmaCreateBuffer

pub unsafe extern "C" fn vmaCreateBuffer(
    allocator: VmaAllocator,
    pBufferCreateInfo: *const BufferCreateInfo,
    pAllocationCreateInfo: *const VmaAllocationCreateInfo,
    pBuffer: *mut Buffer,
    pAllocation: *mut VmaAllocation,
    pAllocationInfo: *mut VmaAllocationInfo
) -> Result

\brief Creates a new VkBuffer, allocates and binds memory for it.

\param allocator \param pBufferCreateInfo \param pAllocationCreateInfo \param[out] pBuffer Buffer that was created. \param[out] pAllocation Allocation that was created. \param[out] pAllocationInfo Optional. Information about allocated memory. It can be later fetched using function vmaGetAllocationInfo().

This function automatically:

-# Creates buffer. -# Allocates appropriate memory for it. -# Binds the buffer with the memory.

If any of these operations fail, buffer and allocation are not created, returned value is negative error code, *pBuffer and *pAllocation are null.

If the function succeeded, you must destroy both buffer and allocation when you no longer need them using either convenience function vmaDestroyBuffer() or separately, using vkDestroyBuffer() and vmaFreeMemory().

If #VMA_ALLOCATOR_CREATE_KHR_DEDICATED_ALLOCATION_BIT flag was used, VK_KHR_dedicated_allocation extension is used internally to query driver whether it requires or prefers the new buffer to have dedicated allocation. If yes, and if dedicated allocation is possible (#VMA_ALLOCATION_CREATE_NEVER_ALLOCATE_BIT is not used), it creates dedicated allocation for this buffer, just like when using #VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.

\note This function creates a new VkBuffer. Sub-allocation of parts of one large buffer, although recommended as a good practice, is out of scope of this library and could be implemented by the user as a higher-level logic on top of VMA.