VulkanMemoryAllocator 0.3.1 → 0.3.2
raw patch · 5 files changed
+33/−13 lines, 5 filesdep ~vulkanPVP ok
version bump matches the API change (PVP)
Dependency ranges changed: vulkan
API changes (from Hackage documentation)
Files
- VulkanMemoryAllocator.cabal +4/−3
- VulkanMemoryAllocator/src/vk_mem_alloc.h +11/−6
- changelog.md +4/−0
- src/VulkanMemoryAllocator.hs +4/−4
- src/lib.cpp +10/−0
VulkanMemoryAllocator.cabal view
@@ -4,10 +4,10 @@ -- -- see: https://github.com/sol/hpack ----- hash: d63790e67481a6422f7936270c7caa8f6245825d2a71741d5e26ea30e9ba5df1+-- hash: 506cde47ec7828e9710cc6f6f85c304cf0e6657408bbbb7e70e5f25e39ea0146 name: VulkanMemoryAllocator-version: 0.3.1+version: 0.3.2 synopsis: Bindings to the VulkanMemoryAllocator library category: Graphics homepage: https://github.com/expipiplus1/vulkan#readme@@ -52,6 +52,7 @@ src default-extensions: AllowAmbiguousTypes CPP DataKinds DefaultSignatures DeriveAnyClass DeriveGeneric DerivingStrategies DuplicateRecordFields FlexibleContexts FlexibleInstances GADTs GeneralizedNewtypeDeriving InstanceSigs LambdaCase MagicHash NoMonomorphismRestriction OverloadedStrings PartialTypeSignatures PatternSynonyms PolyKinds QuantifiedConstraints RankNTypes RecordWildCards RoleAnnotations ScopedTypeVariables StandaloneDeriving Strict TypeApplications TypeFamilyDependencies TypeOperators TypeSynonymInstances UndecidableInstances ViewPatterns ghc-options: -Wall -Wno-unticked-promoted-constructors -Wno-missing-pattern-synonym-signatures -Wno-unused-imports -Wno-missing-signatures -Wno-partial-type-signatures+ cxx-options: -std=c++11 include-dirs: VulkanMemoryAllocator/src cxx-sources:@@ -63,7 +64,7 @@ , bytestring , transformers , vector- , vulkan ==3.3.1.*+ , vulkan ==3.4.* if flag(safe-foreign-calls) cpp-options: -DSAFE_FOREIGN_CALLS if flag(vma-ndebug)
VulkanMemoryAllocator/src/vk_mem_alloc.h view
@@ -146,7 +146,7 @@ At program startup: --# Initialize Vulkan to have `VkPhysicalDevice` and `VkDevice` object. +-# Initialize Vulkan to have `VkPhysicalDevice`, `VkDevice` and `VkInstance` object. -# Fill VmaAllocatorCreateInfo structure and create #VmaAllocator object by calling vmaCreateAllocator(). @@ -154,6 +154,7 @@ VmaAllocatorCreateInfo allocatorInfo = {}; allocatorInfo.physicalDevice = physicalDevice; allocatorInfo.device = device; +allocatorInfo.instance = instance; VmaAllocator allocator; vmaCreateAllocator(&allocatorInfo, &allocator); @@ -1502,6 +1503,7 @@ and the best one depends on specific GPU type, but you can use this simple approach for the start. Prefer to write to such resource sequentially (e.g. using `memcpy`). Don't perform random access or any reads from it on CPU, as it may be very slow. +Also note that textures written directly from the host through a mapped pointer need to be in LINEAR not OPTIMAL layout. \subsection usage_patterns_readback Readback @@ -1534,10 +1536,10 @@ For resources that you frequently write on CPU and read on GPU, many solutions are possible: -# Create one copy in video memory using #VMA_MEMORY_USAGE_GPU_ONLY, - second copy in system memory using #VMA_MEMORY_USAGE_CPU_ONLY and submit explicit tranfer each time. --# Create just single copy using #VMA_MEMORY_USAGE_CPU_TO_GPU, map it and fill it on CPU, + second copy in system memory using #VMA_MEMORY_USAGE_CPU_ONLY and submit explicit transfer each time. +-# Create just a single copy using #VMA_MEMORY_USAGE_CPU_TO_GPU, map it and fill it on CPU, read it directly on GPU. --# Create just single copy using #VMA_MEMORY_USAGE_CPU_ONLY, map it and fill it on CPU, +-# Create just a single copy using #VMA_MEMORY_USAGE_CPU_ONLY, map it and fill it on CPU, read it directly on GPU. Which solution is the most efficient depends on your resource and especially on the GPU. @@ -1565,6 +1567,10 @@ You should take some measurements to decide which option is faster in case of your specific resource. +Note that textures accessed directly from the host through a mapped pointer need to be in LINEAR layout, +which may slow down their usage on the device. +Textures accessed only by the device and transfer operations can use OPTIMAL layout. + If you don't want to specialize your code for specific types of GPUs, you can still make an simple optimization for cases when your resource ends up in mappable memory to use it directly in this case instead of creating CPU-side staging copy. @@ -2583,7 +2589,7 @@ Memory that is both mappable on host (guarantees to be `HOST_VISIBLE`) and preferably fast to access by GPU. CPU access is typically uncached. Writes may be write-combined. - Usage: Resources written frequently by host (dynamic), read by device. E.g. textures, vertex buffers, uniform buffers updated every frame or every draw call. + Usage: Resources written frequently by host (dynamic), read by device. E.g. textures (with LINEAR layout), vertex buffers, uniform buffers updated every frame or every draw call. */ VMA_MEMORY_USAGE_CPU_TO_GPU = 3, /** Memory mappable on host (guarantees to be `HOST_VISIBLE`) and cached. @@ -18651,7 +18657,6 @@ { VMA_ASSERT(allocator); VMA_ASSERT(pInfo); - VMA_HEAVY_ASSERT(VmaValidatePointerArray(pInfo->moveCount, pInfo->pMoves)); VMA_DEBUG_LOG("vmaBeginDefragmentationPass");
changelog.md view
@@ -2,6 +2,10 @@ ## WIP +## [0.3.2] - 2020-06-03+ - Bump VMA version (nfc, just comments)+ - Compile with new `vulkan` version+ ## [0.3.1] - 2020-05-18 - Eq instances for some simple structs, #94 - Add cabal flag for enable deriving Generic for structs, #99
src/VulkanMemoryAllocator.hs view
@@ -174,8 +174,8 @@ import Vulkan.CStruct.Extends (forgetExtensions) import Vulkan.CStruct.Utils (advancePtrBytes) import Vulkan.CStruct.Utils (lowerArrayPtr)-import Vulkan.Core10.BaseType (bool32ToBool)-import Vulkan.Core10.BaseType (boolToBool32)+import Vulkan.Core10.FundamentalTypes (bool32ToBool)+import Vulkan.Core10.FundamentalTypes (boolToBool32) import Control.Exception.Base (bracket) import Control.Monad (unless) import Control.Monad.IO.Class (liftIO)@@ -3506,8 +3506,8 @@ -- Writes may be write-combined. -- -- Usage: Resources written frequently by host (dynamic), read by device.--- E.g. textures, vertex buffers, uniform buffers updated every frame or--- every draw call.+-- E.g. textures (with LINEAR layout), vertex buffers, uniform buffers+-- updated every frame or every draw call. pattern MEMORY_USAGE_CPU_TO_GPU = MemoryUsage 3 -- | Memory mappable on host (guarantees to be @HOST_VISIBLE@) and cached. It -- is roughly equivalent of @D3D12_HEAP_TYPE_READBACK@.
src/lib.cpp view
@@ -1,3 +1,13 @@ #define VMA_IMPLEMENTATION #define VMA_STATIC_VULKAN_FUNCTIONS 0++#ifdef __clang__+#pragma clang diagnostic push+#pragma clang diagnostic ignored "-Wnullability-completeness"+#endif+ #include <vk_mem_alloc.h>++#ifdef __clang__+#pragma clang diagnostic pop+#endif