HORIZON HASKELLDocslts/ghc-9.14.x3e2d5682026-10-11Search names, modules, packages, or :: a typeCtrl K

GHC 9.14.1 · lts/ghc-9.14.x · 3e2d568 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Core10.Buffer

  • 7 types
  • 3 values
  • Packagevulkan-3.27
  • Exports42
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceBuffer.hs
valuecreateBuffer
  1. :: (Extendss BufferCreateInfo a, PokeChain a, MonadIO io)
  2. => Device

    device is the logical device that creates the buffer object.

  3. -> BufferCreateInfo a

    pCreateInfo is a pointer to a BufferCreateInfo structure containing parameters affecting creation of the buffer.

  4. -> "allocator" ::: Maybe AllocationCallbacks

    pAllocator controls host memory allocation as described in the Memory Allocation chapter.

  5. -> io Buffer
#

vkCreateBuffer - Create a new buffer object

Description

Implementations may fail to create a buffer if the effective usage includes the BUFFER_USAGE_2_DESCRIPTOR_HEAP_BIT_EXT flag, and size is greater than the maximum of maxResourceHeapSize and maxSamplerHeapSize. If this happens, ERROR_OUT_OF_DEVICE_MEMORY will be returned.

This is an issue identified with VK_EXT_descriptor_heap, which we plan to tighten up for the KHR version. Applications using VK_EXT_descriptor_heap may wish to avoid suballocating heaps from the same buffer, instead creating one buffer per heap, to avoid situations where this causes issues.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

  • pCreateInfo must be a valid pointer to a valid BufferCreateInfo structure

  • If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure

  • pBuffer must be a valid pointer to a Buffer handle

  • The device must have been created with at least 1 queue

Return Codes

Success
Failure

See Also

VK_VERSION_1_0, AllocationCallbacks, Buffer, BufferCreateInfo, Device

valuedestroyBuffer
  1. :: MonadIO io
  2. => Device

    device is the logical device that destroys the buffer.

  3. -> Buffer

    buffer is the buffer to destroy.

  4. -> "allocator" ::: Maybe AllocationCallbacks

    pAllocator controls host memory allocation as described in the Memory Allocation chapter.

  5. -> io ()
#

vkDestroyBuffer - Destroy a buffer object

Valid Usage

  • All submitted commands that refer to buffer, either directly or via a BufferView, must have completed execution

  • If AllocationCallbacks were provided when buffer was created, a compatible set of callbacks must be provided here

  • If no AllocationCallbacks were provided when buffer was created, pAllocator must be NULL

Valid Usage (Implicit)

  • device must be a valid Device handle

  • If buffer is not NULL_HANDLE, buffer must be a valid Buffer handle

  • If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure

  • If buffer is a valid handle, it must have been created, allocated, or retrieved from device

Host Synchronization

  • Host access to buffer must be externally synchronized

See Also

VK_VERSION_1_0, AllocationCallbacks, Buffer, Device

datadata BufferCreateInfo (es :: [Type])
#

VkBufferCreateInfo - Structure specifying the parameters of a newly created buffer object

Description

usage defines the effective usage flags for the buffer. If the pNext chain includes a BufferUsageFlags2CreateInfo structure, BufferUsageFlags2CreateInfo::usage from that structure is used as the effective usage instead of usage from this structure.

Valid Usage

Valid Usage (Implicit)

See Also

VK_VERSION_1_0, BufferConstraintsInfoFUCHSIA, BufferCreateFlags, BufferUsageFlags, DeviceBufferMemoryRequirements, DeviceSize, SharingMode, StructureType, createBuffer

Constructors

Instances5Extensible, Show, FromCStruct, ToCStruct, Zero
newtypenewtype Buffer
#

VkBuffer - Opaque handle to a buffer object

See Also

VK_DEFINE_NON_DISPATCHABLE_HANDLE, VK_VERSION_1_0, AccelerationStructureCreateInfoKHR, BindBufferMemoryInfo, BufferCaptureDescriptorDataInfoEXT, BufferDeviceAddressInfo, BufferMemoryBarrier, BufferMemoryBarrier2, BufferMemoryRequirementsInfo2, BufferViewCreateInfo, ConditionalRenderingBeginInfoEXT, CopyBufferInfo2, CopyBufferToImageInfo2, CopyImageToBufferInfo2, DedicatedAllocationMemoryAllocateInfoNV, DescriptorBufferBindingPushDescriptorBufferHandleEXT, DescriptorBufferInfo, FrameBoundaryEXT, GeneratedCommandsInfoNV, GeometryAABBNV, GeometryTrianglesNV, IndirectCommandsStreamNV, MemoryDedicatedAllocateInfo, MicromapCreateInfoEXT, SparseBufferMemoryBindInfo, VkVideoDecodeInfoKHR, VkVideoEncodeInfoKHR, bindBufferMemory, cmdBeginTransformFeedbackEXT, cmdBindIndexBuffer, cmdBindIndexBuffer2, cmdBindIndexBuffer2, cmdBindTransformFeedbackBuffersEXT, cmdBindVertexBuffers, cmdBindVertexBuffers2, cmdBindVertexBuffers2, cmdBuildAccelerationStructureNV, cmdCopyBuffer, cmdCopyBufferToImage, cmdCopyImageToBuffer, cmdCopyQueryPoolResults, cmdDispatchIndirect, cmdDrawClusterIndirectHUAWEI, cmdDrawIndexedIndirect, cmdDrawIndexedIndirectCount, cmdDrawIndexedIndirectCount, cmdDrawIndexedIndirectCount, cmdDrawIndirect, cmdDrawIndirectByteCountEXT, cmdDrawIndirectCount, cmdDrawIndirectCount, cmdDrawIndirectCount, cmdDrawMeshTasksIndirectCountEXT, cmdDrawMeshTasksIndirectCountNV, cmdDrawMeshTasksIndirectEXT, cmdDrawMeshTasksIndirectNV, cmdEndTransformFeedbackEXT, cmdFillBuffer, cmdTraceRaysNV, cmdUpdateBuffer, cmdWriteBufferMarker2AMD, cmdWriteBufferMarkerAMD, createBuffer, destroyBuffer, getBufferMemoryRequirements

Constructors

Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
  • Eq BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • Ord BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • Show BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • Storable BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • HasObjectType BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • IsHandle BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
  • Zero BufferDefined in vulkan-3.27 · Vulkan.Core10.Handles
newtypenewtype SharingMode
#

VkSharingMode - Buffer and image sharing modes

Description

  • SHARING_MODE_EXCLUSIVE specifies that access to any range or image subresource of the object will be exclusive to a single queue family at a time.

  • SHARING_MODE_CONCURRENT specifies that concurrent access to any range or image subresource of the object from multiple queue families is supported.

SHARING_MODE_CONCURRENT may result in lower performance access to the buffer or image than SHARING_MODE_EXCLUSIVE.

Ranges of buffers and image subresources of image objects created using SHARING_MODE_EXCLUSIVE must only be accessed by queues in the queue family that has ownership of the resource. Upon creation, such resources are not owned by any queue family; ownership is implicitly acquired upon first use within a queue. Once a resource using SHARING_MODE_EXCLUSIVE is owned by some queue family, unless the maintenance9 feature is enabled, the application must perform a queue family ownership transfer if it wishes to make the memory contents of a range or image subresource accessible to a different queue family. SHARING_MODE_EXCLUSIVE resources that are already owned by a queue family may be acquired by a different queue family without a queue family ownership transfer, but unless the maintenance9 feature is enabled, their contents become undefined.

If the maintenance9 feature is enabled, the contents of buffer resources, and of linear image resources (i.e., those created with tiling set to IMAGE_TILING_LINEAR) are always preserved when they are implicitly acquired by a different queue family on the same logical device (i.e., neither queue family is QUEUE_FAMILY_FOREIGN_EXT or QUEUE_FAMILY_EXTERNAL). This means that whenever the maintenance9 feature is enabled, explicit queue family ownership transfers of buffer and linear image resources between different queue families on the same logical device are optional.

Additionally, if the maintenance9 feature is enabled, the contents of some optimal image resources (i.e., those created with IMAGE_TILING_OPTIMAL) are always preserved when they are implicitly acquired by a different queue family on the same logical device (i.e., neither queue family is QUEUE_FAMILY_FOREIGN_EXT or QUEUE_FAMILY_EXTERNAL). This applies only to optimal images that are being implicitly acquired by a queue family whose index bit is set in the current queue family’s QueueFamilyOwnershipTransferPropertiesKHR::optimalImageTransferToQueueFamilies, and that were created without any of the following bits set in usage:

This means that whenever the maintenance9 feature is enabled, explicit queue family ownership transfers of such image resources between such combinations of queue families are optional. For all other optimal images and/or combinations of queue families, the application must still perform an explicit queue family ownership transfer if it wishes to make the memory contents of an optimal image subresource already owned by a queue family accessible to a different queue family.

Applications are allowed to perform explicit queue family ownership transfers in circumstances where they are not required, but there is no functional nor performance advantage in doing so. Performing explicit transfers in such cases remains supported for backward compatibility and is not recommended for new applications.

Before being used on the first queue, images still require a layout transition from these layouts:

A queue family can take ownership of an image subresource, tensor subresource, or buffer range of a resource created with SHARING_MODE_EXCLUSIVE, without an ownership transfer, in the same way as for a resource that was just created; however, taking ownership in this way has the effect that the contents of the image subresource or buffer range are undefined.

Ranges of buffers, tensor subresources of tensor objects, and image subresources of image objects created using SHARING_MODE_CONCURRENT must only be accessed by queues from the queue families specified through the queueFamilyIndexCount and pQueueFamilyIndices members of the corresponding create info structures.

See Also

VK_VERSION_1_0, BufferCreateInfo, ImageCreateInfo, PhysicalDeviceImageDrmFormatModifierInfoEXT, SwapchainCreateInfoKHR, TensorCreateInfoARM

Constructors

Instances6Eq, Ord, Read, Show, Storable, Zero
newtypenewtype BufferUsageFlagBits
#

VkBufferUsageFlagBits - Bitmask specifying allowed usage of a buffer

Description

See Also

VK_VERSION_1_0, BufferUsageFlags

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …
newtypenewtype BufferCreateFlagBits
#

VkBufferCreateFlagBits - Bitmask specifying additional parameters of a buffer

Description

See Sparse Resource Features and Physical Device Features for details of the sparse memory features supported on a device.

See Also

VK_VERSION_1_0, BufferCreateFlags

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …