vulkan-3.2.0.0: Bindings to the Vulkan graphics API.

Safe HaskellNone
LanguageHaskell2010

Graphics.Vulkan.Core10.DeviceInitialization

Synopsis

Documentation

createInstance :: forall a io. (PokeChain a, MonadIO io) => InstanceCreateInfo a -> ("allocator" ::: Maybe AllocationCallbacks) -> io Instance Source #

vkCreateInstance - Create a new Vulkan instance

Parameters

  • pCreateInfo is a pointer to a InstanceCreateInfo structure controlling creation of the instance.
  • pAllocator controls host memory allocation as described in the Memory Allocation chapter.
  • pInstance points a Instance handle in which the resulting instance is returned.

Description

createInstance verifies that the requested layers exist. If not, createInstance will return ERROR_LAYER_NOT_PRESENT. Next createInstance verifies that the requested extensions are supported (e.g. in the implementation or in any enabled instance layer) and if any requested extension is not supported, createInstance must return ERROR_EXTENSION_NOT_PRESENT. After verifying and enabling the instance layers and extensions the Instance object is created and returned to the application. If a requested extension is only supported by a layer, both the layer and the extension need to be specified at createInstance time for the creation to succeed.

Valid Usage

Valid Usage (Implicit)

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

Return Codes

Success
Failure

See Also

AllocationCallbacks, Instance, InstanceCreateInfo

withInstance :: forall a io r. (PokeChain a, MonadIO io) => (io Instance -> (Instance -> io ()) -> r) -> InstanceCreateInfo a -> Maybe AllocationCallbacks -> r Source #

A convenience wrapper to make a compatible pair of calls to createInstance and destroyInstance

To ensure that destroyInstance is always called: pass bracket (or the allocate function from your favourite resource management library) as the first argument. To just extract the pair pass '(,)' as the first argument.

destroyInstance :: forall io. MonadIO io => Instance -> ("allocator" ::: Maybe AllocationCallbacks) -> io () Source #

vkDestroyInstance - Destroy an instance of Vulkan

Parameters

  • instance is the handle of the instance to destroy.
  • pAllocator controls host memory allocation as described in the Memory Allocation chapter.

Valid Usage

  • All child objects created using instance must have been destroyed prior to destroying instance
  • If AllocationCallbacks were provided when instance was created, a compatible set of callbacks must be provided here
  • If no AllocationCallbacks were provided when instance was created, pAllocator must be NULL

Valid Usage (Implicit)

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

Host Synchronization

  • Host access to instance must be externally synchronized
  • Host access to all PhysicalDevice objects enumerated from instance must be externally synchronized

See Also

AllocationCallbacks, Instance

enumeratePhysicalDevices :: forall io. MonadIO io => Instance -> io (Result, "physicalDevices" ::: Vector PhysicalDevice) Source #

vkEnumeratePhysicalDevices - Enumerates the physical devices accessible to a Vulkan instance

Parameters

  • instance is a handle to a Vulkan instance previously created with createInstance.
  • pPhysicalDeviceCount is a pointer to an integer related to the number of physical devices available or queried, as described below.
  • pPhysicalDevices is either NULL or a pointer to an array of PhysicalDevice handles.

Description

If pPhysicalDevices is NULL, then the number of physical devices available is returned in pPhysicalDeviceCount. Otherwise, pPhysicalDeviceCount must point to a variable set by the user to the number of elements in the pPhysicalDevices array, and on return the variable is overwritten with the number of handles actually written to pPhysicalDevices. If pPhysicalDeviceCount is less than the number of physical devices available, at most pPhysicalDeviceCount structures will be written. If pPhysicalDeviceCount is smaller than the number of physical devices available, INCOMPLETE will be returned instead of SUCCESS, to indicate that not all the available physical devices were returned.

Valid Usage (Implicit)

  • instance must be a valid Instance handle
  • pPhysicalDeviceCount must be a valid pointer to a uint32_t value
  • If the value referenced by pPhysicalDeviceCount is not 0, and pPhysicalDevices is not NULL, pPhysicalDevices must be a valid pointer to an array of pPhysicalDeviceCount PhysicalDevice handles

Return Codes

Success
Failure

See Also

Instance, PhysicalDevice

getDeviceProcAddr :: forall io. MonadIO io => Device -> ("name" ::: ByteString) -> io PFN_vkVoidFunction Source #

vkGetDeviceProcAddr - Return a function pointer for a command

Parameters

The table below defines the various use cases for getDeviceProcAddr and expected return value for each case.

Description

The returned function pointer is of type PFN_vkVoidFunction, and must be cast to the type of the command being queried before use. The function pointer must only be called with a dispatchable object (the first parameter) that is device or a child of device.

device pName return value
NULL *1 undefined
invalid device *1 undefined
device NULL undefined
device core device-level Vulkan command fp2
device enabled extension device-level commands fp2
any other case, not covered above NULL

getDeviceProcAddr behavior

1
"*" means any representable value for the parameter (including valid values, invalid values, and NULL).
2
The returned function pointer must only be called with a dispatchable object (the first parameter) that is device or a child of device e.g. Device, Queue, or CommandBuffer.

Valid Usage (Implicit)

See Also

PFN_vkVoidFunction, Device

getInstanceProcAddr :: forall io. MonadIO io => Instance -> ("name" ::: ByteString) -> io PFN_vkVoidFunction Source #

vkGetInstanceProcAddr - Return a function pointer for a command

Parameters

  • instance is the instance that the function pointer will be compatible with, or NULL for commands not dependent on any instance.
  • pName is the name of the command to obtain.

Description

getInstanceProcAddr itself is obtained in a platform- and loader- specific manner. Typically, the loader library will export this command as a function symbol, so applications can link against the loader library, or load it dynamically and look up the symbol using platform-specific APIs.

The table below defines the various use cases for getInstanceProcAddr and expected return value (“fp” is “function pointer”) for each case.

The returned function pointer is of type PFN_vkVoidFunction, and must be cast to the type of the command being queried before use.

instance pName return value
*1 NULL undefined
invalid non-NULL instance *1 undefined
NULL enumerateInstanceVersion fp
NULL enumerateInstanceExtensionProperties fp
NULL enumerateInstanceLayerProperties fp
NULL createInstance fp
instance core Vulkan command fp2
instance enabled instance extension commands for instance fp2
instance available device extension3 commands for instance fp2
any other case, not covered above NULL

getInstanceProcAddr behavior

1
"*" means any representable value for the parameter (including valid values, invalid values, and NULL).
2
The returned function pointer must only be called with a dispatchable object (the first parameter) that is instance or a child of instance, e.g. Instance, PhysicalDevice, Device, Queue, or CommandBuffer.
3
An “available device extension” is a device extension supported by any physical device enumerated by instance.

Valid Usage (Implicit)

  • If instance is not NULL, instance must be a valid Instance handle
  • pName must be a null-terminated UTF-8 string

See Also

PFN_vkVoidFunction, Instance

getPhysicalDeviceProperties :: forall io. MonadIO io => PhysicalDevice -> io PhysicalDeviceProperties Source #

vkGetPhysicalDeviceProperties - Returns properties of a physical device

Parameters

  • physicalDevice is the handle to the physical device whose properties will be queried.

Valid Usage (Implicit)

See Also

PhysicalDevice, PhysicalDeviceProperties

getPhysicalDeviceQueueFamilyProperties :: forall io. MonadIO io => PhysicalDevice -> io ("queueFamilyProperties" ::: Vector QueueFamilyProperties) Source #

vkGetPhysicalDeviceQueueFamilyProperties - Reports properties of the queues of the specified physical device

Parameters

  • physicalDevice is the handle to the physical device whose properties will be queried.
  • pQueueFamilyPropertyCount is a pointer to an integer related to the number of queue families available or queried, as described below.
  • pQueueFamilyProperties is either NULL or a pointer to an array of QueueFamilyProperties structures.

Description

If pQueueFamilyProperties is NULL, then the number of queue families available is returned in pQueueFamilyPropertyCount. Implementations must support at least one queue family. Otherwise, pQueueFamilyPropertyCount must point to a variable set by the user to the number of elements in the pQueueFamilyProperties array, and on return the variable is overwritten with the number of structures actually written to pQueueFamilyProperties. If pQueueFamilyPropertyCount is less than the number of queue families available, at most pQueueFamilyPropertyCount structures will be written.

Valid Usage (Implicit)

  • pQueueFamilyPropertyCount must be a valid pointer to a uint32_t value
  • If the value referenced by pQueueFamilyPropertyCount is not 0, and pQueueFamilyProperties is not NULL, pQueueFamilyProperties must be a valid pointer to an array of pQueueFamilyPropertyCount QueueFamilyProperties structures

See Also

PhysicalDevice, QueueFamilyProperties

getPhysicalDeviceMemoryProperties :: forall io. MonadIO io => PhysicalDevice -> io PhysicalDeviceMemoryProperties Source #

vkGetPhysicalDeviceMemoryProperties - Reports memory information for the specified physical device

Parameters

  • physicalDevice is the handle to the device to query.

Valid Usage (Implicit)

See Also

PhysicalDevice, PhysicalDeviceMemoryProperties

getPhysicalDeviceFeatures :: forall io. MonadIO io => PhysicalDevice -> io PhysicalDeviceFeatures Source #

vkGetPhysicalDeviceFeatures - Reports capabilities of a physical device

Parameters

  • physicalDevice is the physical device from which to query the supported features.
  • pFeatures is a pointer to a PhysicalDeviceFeatures structure in which the physical device features are returned. For each feature, a value of TRUE specifies that the feature is supported on this physical device, and FALSE specifies that the feature is not supported.

Valid Usage (Implicit)

See Also

PhysicalDevice, PhysicalDeviceFeatures

getPhysicalDeviceFormatProperties :: forall io. MonadIO io => PhysicalDevice -> Format -> io FormatProperties Source #

vkGetPhysicalDeviceFormatProperties - Lists physical device’s format capabilities

Parameters

  • physicalDevice is the physical device from which to query the format properties.
  • format is the format whose properties are queried.
  • pFormatProperties is a pointer to a FormatProperties structure in which physical device properties for format are returned.

Valid Usage (Implicit)

See Also

Format, FormatProperties, PhysicalDevice

getPhysicalDeviceImageFormatProperties :: forall io. MonadIO io => PhysicalDevice -> Format -> ImageType -> ImageTiling -> ImageUsageFlags -> ImageCreateFlags -> io ImageFormatProperties Source #

vkGetPhysicalDeviceImageFormatProperties - Lists physical device’s image format capabilities

Parameters

  • physicalDevice is the physical device from which to query the image capabilities.

Description

The format, type, tiling, usage, and flags parameters correspond to parameters that would be consumed by createImage (as members of ImageCreateInfo).

If format is not a supported image format, or if the combination of format, type, tiling, usage, and flags is not supported for images, then getPhysicalDeviceImageFormatProperties returns ERROR_FORMAT_NOT_SUPPORTED.

The limitations on an image format that are reported by getPhysicalDeviceImageFormatProperties have the following property: if usage1 and usage2 of type ImageUsageFlags are such that the bits set in usage1 are a subset of the bits set in usage2, and flags1 and flags2 of type ImageCreateFlags are such that the bits set in flags1 are a subset of the bits set in flags2, then the limitations for usage1 and flags1 must be no more strict than the limitations for usage2 and flags2, for all values of format, type, and tiling.

Return Codes

Success
Failure

See Also

Format, ImageCreateFlags, ImageFormatProperties, ImageTiling, ImageType, ImageUsageFlags, PhysicalDevice

data PhysicalDeviceProperties Source #

VkPhysicalDeviceProperties - Structure specifying physical device properties

Description

Note

The value of apiVersion may be different than the version returned by enumerateInstanceVersion; either higher or lower. In such cases, the application must not use functionality that exceeds the version of Vulkan associated with a given object. The pApiVersion parameter returned by enumerateInstanceVersion is the version associated with a Instance and its children, except for a PhysicalDevice and its children. PhysicalDeviceProperties::apiVersion is the version associated with a PhysicalDevice and its children.

The vendorID and deviceID fields are provided to allow applications to adapt to device characteristics that are not adequately exposed by other Vulkan queries.

Note

These may include performance profiles, hardware errata, or other characteristics.

The vendor identified by vendorID is the entity responsible for the most salient characteristics of the underlying implementation of the PhysicalDevice being queried.

Note

For example, in the case of a discrete GPU implementation, this should be the GPU chipset vendor. In the case of a hardware accelerator integrated into a system-on-chip (SoC), this should be the supplier of the silicon IP used to create the accelerator.

If the vendor has a PCI vendor ID, the low 16 bits of vendorID must contain that PCI vendor ID, and the remaining bits must be set to zero. Otherwise, the value returned must be a valid Khronos vendor ID, obtained as described in the Vulkan Documentation and Extensions: Procedures and Conventions document in the section “Registering a Vendor ID with Khronos”. Khronos vendor IDs are allocated starting at 0x10000, to distinguish them from the PCI vendor ID namespace. Khronos vendor IDs are symbolically defined in the VendorId type.

The vendor is also responsible for the value returned in deviceID. If the implementation is driven primarily by a PCI device with a PCI device ID, the low 16 bits of deviceID must contain that PCI device ID, and the remaining bits must be set to zero. Otherwise, the choice of what values to return may be dictated by operating system or platform policies - but should uniquely identify both the device version and any major configuration options (for example, core count in the case of multicore devices).

Note

The same device ID should be used for all physical implementations of that device version and configuration. For example, all uses of a specific silicon IP GPU version and configuration should use the same device ID, even if those uses occur in different SoCs.

See Also

PhysicalDeviceLimits, PhysicalDeviceProperties2, PhysicalDeviceSparseProperties, PhysicalDeviceType, getPhysicalDeviceProperties

Constructors

PhysicalDeviceProperties 

Fields

data ApplicationInfo Source #

VkApplicationInfo - Structure specifying application info

Description

Vulkan 1.0 implementations were required to return ERROR_INCOMPATIBLE_DRIVER if apiVersion was larger than 1.0. Implementations that support Vulkan 1.1 or later must not return ERROR_INCOMPATIBLE_DRIVER for any value of apiVersion.

Note

Because Vulkan 1.0 implementations may fail with ERROR_INCOMPATIBLE_DRIVER, applications should determine the version of Vulkan available before calling createInstance. If the getInstanceProcAddr returns NULL for enumerateInstanceVersion, it is a Vulkan 1.0 implementation. Otherwise, the application can call enumerateInstanceVersion to determine the version of Vulkan.

As long as the instance supports at least Vulkan 1.1, an application can use different versions of Vulkan with an instance than it does with a device or physical device.

Note

The Khronos validation layers will treat apiVersion as the highest API version the application targets, and will validate API usage against the minimum of that version and the implementation version (instance or device, depending on context). If an application tries to use functionality from a greater version than this, a validation error will be triggered.

For example, if the instance supports Vulkan 1.1 and three physical devices support Vulkan 1.0, Vulkan 1.1, and Vulkan 1.2, respectively, and if the application sets apiVersion to 1.2, the application can use the following versions of Vulkan:

  • Vulkan 1.0 can be used with the instance and with all physical devices.
  • Vulkan 1.1 can be used with the instance and with the physical devices that support Vulkan 1.1 and Vulkan 1.2.
  • Vulkan 1.2 can be used with the physical device that supports Vulkan 1.2.

If we modify the above example so that the application sets apiVersion to 1.1, then the application must not use Vulkan 1.2 functionality on the physical device that supports Vulkan 1.2.

Implicit layers must be disabled if they do not support a version at least as high as apiVersion. See the Vulkan Loader Specification and Architecture Overview document for additional information.

Note

Providing a NULL InstanceCreateInfo::pApplicationInfo or providing an apiVersion of 0 is equivalent to providing an apiVersion of VK_MAKE_VERSION(1,0,0).

Valid Usage (Implicit)

  • pNext must be NULL
  • If pApplicationName is not NULL, pApplicationName must be a null-terminated UTF-8 string
  • If pEngineName is not NULL, pEngineName must be a null-terminated UTF-8 string

See Also

InstanceCreateInfo, StructureType

Constructors

ApplicationInfo 

Fields

data InstanceCreateInfo (es :: [Type]) Source #

VkInstanceCreateInfo - Structure specifying parameters of a newly created instance

Valid Usage (Implicit)

  • Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of DebugReportCallbackCreateInfoEXT, DebugUtilsMessengerCreateInfoEXT, ValidationFeaturesEXT, or ValidationFlagsEXT
  • The sType value of each struct in the pNext chain must be unique
  • flags must be 0
  • If pApplicationInfo is not NULL, pApplicationInfo must be a valid pointer to a valid ApplicationInfo structure
  • If enabledLayerCount is not 0, ppEnabledLayerNames must be a valid pointer to an array of enabledLayerCount null-terminated UTF-8 strings
  • If enabledExtensionCount is not 0, ppEnabledExtensionNames must be a valid pointer to an array of enabledExtensionCount null-terminated UTF-8 strings

See Also

ApplicationInfo, InstanceCreateFlags, StructureType, createInstance

Constructors

InstanceCreateInfo 

Fields

Instances
Extensible InstanceCreateInfo Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Show (Chain es) => Show (InstanceCreateInfo es) Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

PeekChain es => FromCStruct (InstanceCreateInfo es) Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

PokeChain es => ToCStruct (InstanceCreateInfo es) Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

es ~ ([] :: [Type]) => Zero (InstanceCreateInfo es) Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

data QueueFamilyProperties Source #

VkQueueFamilyProperties - Structure providing information about a queue family

Description

The value returned in minImageTransferGranularity has a unit of compressed texel blocks for images having a block-compressed format, and a unit of texels otherwise.

Possible values of minImageTransferGranularity are:

  • (0,0,0) which indicates that only whole mip levels must be transferred using the image transfer operations on the corresponding queues. In this case, the following restrictions apply to all offset and extent parameters of image transfer operations:

    • The x, y, and z members of a Offset3D parameter must always be zero.
    • The width, height, and depth members of a Extent3D parameter must always match the width, height, and depth of the image subresource corresponding to the parameter, respectively.
  • (Ax, Ay, Az) where Ax, Ay, and Az are all integer powers of two. In this case the following restrictions apply to all image transfer operations:

    • x, y, and z of a Offset3D parameter must be integer multiples of Ax, Ay, and Az, respectively.
    • width of a Extent3D parameter must be an integer multiple of Ax, or else x + width must equal the width of the image subresource corresponding to the parameter.
    • height of a Extent3D parameter must be an integer multiple of Ay, or else y + height must equal the height of the image subresource corresponding to the parameter.
    • depth of a Extent3D parameter must be an integer multiple of Az, or else z + depth must equal the depth of the image subresource corresponding to the parameter.
    • If the format of the image corresponding to the parameters is one of the block-compressed formats then for the purposes of the above calculations the granularity must be scaled up by the compressed texel block dimensions.

Queues supporting graphics and/or compute operations must report (1,1,1) in minImageTransferGranularity, meaning that there are no additional restrictions on the granularity of image transfer operations for these queues. Other queues supporting image transfer operations are only required to support whole mip level transfers, thus minImageTransferGranularity for queues belonging to such queue families may be (0,0,0).

The Device Memory section describes memory properties queried from the physical device.

For physical device feature queries see the Features chapter.

See Also

Extent3D, QueueFamilyProperties2, QueueFlags, getPhysicalDeviceQueueFamilyProperties

Constructors

QueueFamilyProperties 

Fields

  • queueFlags :: QueueFlags

    queueFlags is a bitmask of QueueFlagBits indicating capabilities of the queues in this queue family.

  • queueCount :: Word32

    queueCount is the unsigned integer count of queues in this queue family. Each queue family must support at least one queue.

  • timestampValidBits :: Word32

    timestampValidBits is the unsigned integer count of meaningful bits in the timestamps written via cmdWriteTimestamp. The valid range for the count is 36..64 bits, or a value of 0, indicating no support for timestamps. Bits outside the valid range are guaranteed to be zeros.

  • minImageTransferGranularity :: Extent3D

    minImageTransferGranularity is the minimum granularity supported for image transfer operations on the queues in this queue family.

data PhysicalDeviceMemoryProperties Source #

VkPhysicalDeviceMemoryProperties - Structure specifying physical device memory properties

Description

The PhysicalDeviceMemoryProperties structure describes a number of memory heaps as well as a number of memory types that can be used to access memory allocated in those heaps. Each heap describes a memory resource of a particular size, and each memory type describes a set of memory properties (e.g. host cached vs uncached) that can be used with a given memory heap. Allocations using a particular memory type will consume resources from the heap indicated by that memory type’s heap index. More than one memory type may share each heap, and the heaps and memory types provide a mechanism to advertise an accurate size of the physical memory resources while allowing the memory to be used with a variety of different properties.

The number of memory heaps is given by memoryHeapCount and is less than or equal to MAX_MEMORY_HEAPS. Each heap is described by an element of the memoryHeaps array as a MemoryHeap structure. The number of memory types available across all memory heaps is given by memoryTypeCount and is less than or equal to MAX_MEMORY_TYPES. Each memory type is described by an element of the memoryTypes array as a MemoryType structure.

At least one heap must include MEMORY_HEAP_DEVICE_LOCAL_BIT in MemoryHeap::flags. If there are multiple heaps that all have similar performance characteristics, they may all include MEMORY_HEAP_DEVICE_LOCAL_BIT. In a unified memory architecture (UMA) system there is often only a single memory heap which is considered to be equally “local” to the host and to the device, and such an implementation must advertise the heap as device-local.

Each memory type returned by getPhysicalDeviceMemoryProperties must have its propertyFlags set to one of the following values:

There must be at least one memory type with both the MEMORY_PROPERTY_HOST_VISIBLE_BIT and MEMORY_PROPERTY_HOST_COHERENT_BIT bits set in its propertyFlags. There must be at least one memory type with the MEMORY_PROPERTY_DEVICE_LOCAL_BIT bit set in its propertyFlags. If the deviceCoherentMemory feature is enabled, there must be at least one memory type with the MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD bit set in its propertyFlags.

For each pair of elements X and Y returned in memoryTypes, X must be placed at a lower index position than Y if:

  • the set of bit flags returned in the propertyFlags member of X is a strict subset of the set of bit flags returned in the propertyFlags member of Y; or
  • the propertyFlags members of X and Y are equal, and X belongs to a memory heap with greater performance (as determined in an implementation-specific manner) ; or
  • the propertyFlags members of Y includes MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD or MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD and X does not

Note

There is no ordering requirement between X and Y elements for the case their propertyFlags members are not in a subset relation. That potentially allows more than one possible way to order the same set of memory types. Notice that the list of all allowed memory property flag combinations is written in a valid order. But if instead MEMORY_PROPERTY_DEVICE_LOCAL_BIT was before MEMORY_PROPERTY_HOST_VISIBLE_BIT | MEMORY_PROPERTY_HOST_COHERENT_BIT, the list would still be in a valid order.

There may be a performance penalty for using device coherent or uncached device memory types, and using these accidentally is undesirable. In order to avoid this, memory types with these properties always appear at the end of the list; but are subject to the same rules otherwise.

This ordering requirement enables applications to use a simple search loop to select the desired memory type along the lines of:

// Find a memory in `memoryTypeBitsRequirement` that includes all of `requiredProperties`
int32_t findProperties(const VkPhysicalDeviceMemoryProperties* pMemoryProperties,
                       uint32_t memoryTypeBitsRequirement,
                       VkMemoryPropertyFlags requiredProperties) {
    const uint32_t memoryCount = pMemoryProperties->memoryTypeCount;
    for (uint32_t memoryIndex = 0; memoryIndex < memoryCount; ++memoryIndex) {
        const uint32_t memoryTypeBits = (1 << memoryIndex);
        const bool isRequiredMemoryType = memoryTypeBitsRequirement & memoryTypeBits;

        const VkMemoryPropertyFlags properties =
            pMemoryProperties->memoryTypes[memoryIndex].propertyFlags;
        const bool hasRequiredProperties =
            (properties & requiredProperties) == requiredProperties;

        if (isRequiredMemoryType && hasRequiredProperties)
            return static_cast<int32_t>(memoryIndex);
    }

    // failed to find memory type
    return -1;
}

// Try to find an optimal memory type, or if it does not exist try fallback memory type
// `device` is the VkDevice
// `image` is the VkImage that requires memory to be bound
// `memoryProperties` properties as returned by vkGetPhysicalDeviceMemoryProperties
// `requiredProperties` are the property flags that must be present
// `optimalProperties` are the property flags that are preferred by the application
VkMemoryRequirements memoryRequirements;
vkGetImageMemoryRequirements(device, image, &memoryRequirements);
int32_t memoryType =
    findProperties(&memoryProperties, memoryRequirements.memoryTypeBits, optimalProperties);
if (memoryType == -1) // not found; try fallback properties
    memoryType =
        findProperties(&memoryProperties, memoryRequirements.memoryTypeBits, requiredProperties);

See Also

MemoryHeap, MemoryType, PhysicalDeviceMemoryProperties2, getPhysicalDeviceMemoryProperties

Constructors

PhysicalDeviceMemoryProperties 

Fields

data MemoryType Source #

VkMemoryType - Structure specifying memory type

See Also

MemoryPropertyFlags, PhysicalDeviceMemoryProperties

Constructors

MemoryType 

Fields

data MemoryHeap Source #

VkMemoryHeap - Structure specifying a memory heap

See Also

DeviceSize, MemoryHeapFlags, PhysicalDeviceMemoryProperties

Constructors

MemoryHeap 

Fields

data FormatProperties Source #

VkFormatProperties - Structure specifying image format properties

Description

Note

If no format feature flags are supported, the format itself is not supported, and images of that format cannot be created.

If format is a block-compressed format, then bufferFeatures must not support any features for the format.

If format is not a multi-plane format then linearTilingFeatures and optimalTilingFeatures must not contain FORMAT_FEATURE_DISJOINT_BIT.

See Also

FormatFeatureFlags, FormatProperties2, getPhysicalDeviceFormatProperties

Constructors

FormatProperties 

Fields

Instances
Show FormatProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Storable FormatProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

FromCStruct FormatProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

ToCStruct FormatProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Zero FormatProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

data ImageFormatProperties Source #

VkImageFormatProperties - Structure specifying an image format properties

Members

  • maxExtent are the maximum image dimensions. See the Allowed Extent Values section below for how these values are constrained by type.

Description

Note

There is no mechanism to query the size of an image before creating it, to compare that size against maxResourceSize. If an application attempts to create an image that exceeds this limit, the creation will fail and createImage will return ERROR_OUT_OF_DEVICE_MEMORY. While the advertised limit must be at least 231, it may not be possible to create an image that approaches that size, particularly for IMAGE_TYPE_1D.

If the combination of parameters to getPhysicalDeviceImageFormatProperties is not supported by the implementation for use in createImage, then all members of ImageFormatProperties will be filled with zero.

Note

Filling ImageFormatProperties with zero for unsupported formats is an exception to the usual rule that output structures have undefined contents on error. This exception was unintentional, but is preserved for backwards compatibility.

See Also

DeviceSize, Extent3D, ExternalImageFormatPropertiesNV, ImageFormatProperties2, SampleCountFlags, getPhysicalDeviceImageFormatProperties

data PhysicalDeviceFeatures Source #

VkPhysicalDeviceFeatures - Structure describing the fine-grained features that can be supported by an implementation

Members

The members of the PhysicalDeviceFeatures structure describe the following features:

See Also

Bool32, DeviceCreateInfo, PhysicalDeviceFeatures2, getPhysicalDeviceFeatures

Constructors

PhysicalDeviceFeatures 

Fields

Instances
Show PhysicalDeviceFeatures Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Storable PhysicalDeviceFeatures Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

FromCStruct PhysicalDeviceFeatures Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

ToCStruct PhysicalDeviceFeatures Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Zero PhysicalDeviceFeatures Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

data PhysicalDeviceSparseProperties Source #

VkPhysicalDeviceSparseProperties - Structure specifying physical device sparse memory properties

See Also

Bool32, PhysicalDeviceProperties

Constructors

PhysicalDeviceSparseProperties 

Fields

  • residencyStandard2DBlockShape :: Bool

    residencyStandard2DBlockShape is TRUE if the physical device will access all single-sample 2D sparse resources using the standard sparse image block shapes (based on image format), as described in the Standard Sparse Image Block Shapes (Single Sample) table. If this property is not supported the value returned in the imageGranularity member of the SparseImageFormatProperties structure for single-sample 2D images is not required to match the standard sparse image block dimensions listed in the table.

  • residencyStandard2DMultisampleBlockShape :: Bool

    residencyStandard2DMultisampleBlockShape is TRUE if the physical device will access all multisample 2D sparse resources using the standard sparse image block shapes (based on image format), as described in the Standard Sparse Image Block Shapes (MSAA) table. If this property is not supported, the value returned in the imageGranularity member of the SparseImageFormatProperties structure for multisample 2D images is not required to match the standard sparse image block dimensions listed in the table.

  • residencyStandard3DBlockShape :: Bool

    residencyStandard3DBlockShape is TRUE if the physical device will access all 3D sparse resources using the standard sparse image block shapes (based on image format), as described in the Standard Sparse Image Block Shapes (Single Sample) table. If this property is not supported, the value returned in the imageGranularity member of the SparseImageFormatProperties structure for 3D images is not required to match the standard sparse image block dimensions listed in the table.

  • residencyAlignedMipSize :: Bool

    residencyAlignedMipSize is TRUE if images with mip level dimensions that are not integer multiples of the corresponding dimensions of the sparse image block may be placed in the mip tail. If this property is not reported, only mip levels with dimensions smaller than the imageGranularity member of the SparseImageFormatProperties structure will be placed in the mip tail. If this property is reported the implementation is allowed to return SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT in the flags member of SparseImageFormatProperties, indicating that mip level dimensions that are not integer multiples of the corresponding dimensions of the sparse image block will be placed in the mip tail.

  • residencyNonResidentStrict :: Bool

    residencyNonResidentStrict specifies whether the physical device can consistently access non-resident regions of a resource. If this property is TRUE, access to non-resident regions of resources will be guaranteed to return values as if the resource were populated with 0; writes to non-resident regions will be discarded.

Instances
Show PhysicalDeviceSparseProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Storable PhysicalDeviceSparseProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

FromCStruct PhysicalDeviceSparseProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

ToCStruct PhysicalDeviceSparseProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Zero PhysicalDeviceSparseProperties Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

data PhysicalDeviceLimits Source #

VkPhysicalDeviceLimits - Structure reporting implementation-dependent physical device limits

Members

The PhysicalDeviceLimits are properties of the physical device. These are available in the limits member of the PhysicalDeviceProperties structure which is returned from getPhysicalDeviceProperties.

Description

1
For all bitmasks of SampleCountFlagBits, the sample count limits defined above represent the minimum supported sample counts for each image type. Individual images may support additional sample counts, which are queried using getPhysicalDeviceImageFormatProperties as described in Supported Sample Counts.

See Also

Bool32, DeviceSize, PhysicalDeviceProperties, SampleCountFlags

Constructors

PhysicalDeviceLimits 

Fields

Instances
Show PhysicalDeviceLimits Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Storable PhysicalDeviceLimits Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

FromCStruct PhysicalDeviceLimits Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

ToCStruct PhysicalDeviceLimits Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization

Zero PhysicalDeviceLimits Source # 
Instance details

Defined in Graphics.Vulkan.Core10.DeviceInitialization