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

GHC 9.14.1 · lts/ghc-9.14.x · 45dd537 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_KHR_device_fault

Name

VK_KHR_device_fault - device extension

VK_KHR_device_fault

Name String

VK_KHR_device_fault

Extension Type

Device extension

Registered Extension Number

574

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_get_physical_device_properties2

or

Vulkan Version 1.1

Contact
Extension Proposal

VK_KHR_device_fault

Other Extension Metadata

Last Modified Date

2026-03-18

IP Status

No known IP claims.

Contributors
  • Ralph Potter, Samsung

  • Craig Graham, Samsung

  • Stuart Smith, AMD

  • Jan-Harald Fredriksen, ARM

  • Mark Bellamy, ARM

  • Andrew Ellem, Google

  • Alex Walters, IMG

  • Jeff Bolz, NVIDIA

  • Baldur Karlsson, Valve

  • Adrian Ravai, Samsung

  • Peter Gal, Samsung

  • Matthew Netsch, QUALCOMM

  • Tobias Hector, AMD

  • Alan Harrison, AMD

  • Vikram Tarikere, IMG

  • Jon Leech, Khronos

  • Samuel Pitoiset, Valve

Description

Device loss can be triggered by a variety of issues, including invalid API usage, implementation errors, or hardware failures. This extension introduces two new commands:

getDeviceFaultReportsKHR allows developers to query for additional information on GPU faults which may have caused device loss, and to generate binary crash dumps, which may be loaded into external tools for further diagnosis. Additionally this command allows developers to query for additional information on GPU faults which were internally recovered by the implementation.

getDeviceFaultReportsKHR differs from getDeviceFaultInfoEXT in that it can be called at any time, is able to report faults which do not result in ERROR_DEVICE_LOST and allows the caller to wait for such an error to occur.

getDeviceFaultDebugInfoKHR provides a separate interface which must only be called when a device loss has occurred to provide extended GPU vendor specific crash post-mortem information.

New Commands

New Structures

New Enums

New Bitmasks

New Enum Constants

Version History

  • Revision 0, 2024-03-01 (Ralph Potter)

    • Internal Revision

  • Revision 1, 2025-06-10 (Craig Graham)

    • Revised API to support async fault queries.

See Also

No cross-references are available

Document Notes

For more information, see the Vulkan Specification.

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

  • 13 types
  • 2 values
  • Packagevulkan-3.27
  • Exports32
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_KHR_device_fault.hs
valuegetDeviceFaultReportsKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device from which to query the diagnostic fault information.

  3. -> "timeout" ::: Word64

    timeout is the timeout period in units of nanoseconds. timeout is adjusted to the closest value allowed by the implementation-dependent timeout accuracy, which may be substantially longer than one nanosecond, and may be longer than the requested period.

  4. -> io (Result, "faultInfo" ::: Vector DeviceFaultInfoKHR)
#

vkGetDeviceFaultReportsKHR - Reports fault information for the specified device

Description

If at least one fault report is available when getDeviceFaultReportsKHR is called, then getDeviceFaultReportsKHR returns immediately. If no faults have occurred at the time getDeviceFaultReportsKHR is called, then getDeviceFaultReportsKHR will block and wait until a fault occurs and a report becomes available or until the timeout has expired, whichever is sooner.

If timeout is zero, then getDeviceFaultReportsKHR does not wait, but simply returns the current fault count and reports. TIMEOUT will be returned in this case if no faults have occurred, even though no actual wait was performed.

If a fault has occurred before the timeout has expired, getDeviceFaultReportsKHR returns SUCCESS. Otherwise, getDeviceFaultReportsKHR returns TIMEOUT after the timeout has expired.

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

If more than one fault report is available, they will be returned in order of occurrence via pFaultInfo.

Each individual fault report is returned exactly once.

getDeviceFaultReportsKHR() may be invoked in parallel on different threads, in which case each invocation for a given device will return a unique set of reports. No fault report being returned to more than one invocation.

Valid Usage (Implicit)

  • device must be a valid Device handle

  • pFaultCounts must be a valid pointer to a uint32_t value

  • If pFaultInfo is not NULL, pFaultInfo must be a valid pointer to an array of pFaultCounts DeviceFaultInfoKHR structures

  • If pFaultInfo is not NULL, the value referenced by pFaultCounts must be greater than 0

Return Codes

Success
Failure

See Also

VK_KHR_device_fault, Device, DeviceFaultInfoKHR

valuegetDeviceFaultDebugInfoKHR
  1. :: (Extendss DeviceFaultDebugInfoKHR a, PokeChain a, PeekChain a, MonadIO io)
  2. => Device

    device is the logical device from which to query the crash dump.

    device must be lost

    device must be a valid Device handle

  3. -> io (Result, DeviceFaultDebugInfoKHR a)
#

vkGetDeviceFaultDebugInfoKHR - Retrieve vendor-specific crash dump data for the specified logical device

Description

If pDebugInfo->pVendorBinaryData is NULL, then the size of any vendor-specific binary crash dump is returned in pDebugInfo->vendorBinarySize.

If the pDebugInfo->pVendorBinaryData is not NULL then it must point to a buffer of size pDebugInfo->vendorBinarySize bytes.

On return, pDebugInfo->vendorBinarySize will be overwritten with the number of bytes actually written to the pDebugInfo->pVendorBinaryData.

If pDebugInfo->vendorBinaryData is not NULL, then subsequent calls to getDeviceFaultDebugInfoKHR for the same device must return identical binary values in the pDebugInfo->pVendorBinaryData buffer up to the limit defined by pDebugInfo->vendorBinarySize.

If the vendor-specific crash dumps feature is not enabled, then implementations must set pDebugInfo->vendorBinarySize to zero and must not modify pDebugInfo->pVendorBinaryData.

Return Codes

Success
Failure

See Also

VK_KHR_device_fault, Device, DeviceFaultDebugInfoKHR

VkDeviceFaultAddressInfoKHR - Structure specifying GPU virtual address information

Description

The combination of reportedAddress and addressPrecision allow the possible range of addresses to be calculated, such that:

lower_address = (pInfo->reportedAddress & ~(pInfo->addressPrecision-1))
upper_address = (pInfo->reportedAddress |  (pInfo->addressPrecision-1))

It is valid for the reportedAddress to contain a more precise address than indicated by addressPrecision. In this case, the value of reportedAddress should be treated as an additional hint as to the value of the address that triggered the page fault, or to the value of an instruction pointer.

See Also

VK_EXT_device_fault, VK_KHR_device_fault, DeviceAddress, DeviceFaultAddressTypeKHR, DeviceFaultInfoEXT, DeviceFaultInfoKHR, DeviceSize

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkDeviceFaultVendorInfoKHR - Structure specifying vendor-specific fault information

See Also

VK_EXT_device_fault, VK_KHR_device_fault, DeviceFaultInfoEXT, DeviceFaultInfoKHR

Constructors

Instances5Show, Storable, FromCStruct, ToCStruct, Zero
datadata DeviceFaultInfoKHR
#

VkDeviceFaultInfoKHR - Structure specifying device fault information

Description

An implementation should populate as many members of DeviceFaultInfoKHR as possible, given the information available at the time of the fault and the constraints of the implementation itself.

A single error may generate multiple instances of DeviceFaultInfoKHR. For example, multiple page faults may be generated, with the faultAddress member of each instance identifying a different memory address. In this case, all instances of DeviceFaultInfoKHR should share the same groupID where the implementation can reasonably ascertain this association.

Due to hardware limitations, faultAddressInfo and instructionAddressInfo describe ranges of GPU virtual address space, rather than precise addresses. The precise memory address accessed or the precise value of the instruction pointer must lie within the region described.

Each DeviceFaultInfoKHR reported may (depending on the flags set) provide:

  • A memory access which may have triggered a page fault and may have contributed to device loss

  • The value of an active instruction pointer at the time a fault occurred. This value may be indicative of the active pipeline or shader at the time of device loss

Comparison of the GPU virtual addresses described by faultAddressInfo or instructionAddressInfo to GPU virtual address ranges reported by the VK_EXT_device_address_binding_report extension may allow applications to correlate between these addresses and Vulkan objects. Applications should be aware that these addresses may also correspond to resources internal to an implementation, which will not be reported via the VK_EXT_device_address_binding_report extension.

Valid Usage (Implicit)

See Also

VK_KHR_device_fault, DeviceFaultAddressInfoKHR, DeviceFaultFlagsKHR, DeviceFaultVendorInfoKHR, StructureType, getDeviceFaultReportsKHR

Constructors

Instances5Show, Storable, FromCStruct, ToCStruct, Zero
datadata DeviceFaultDebugInfoKHR (es :: [Type])
#

VkDeviceFaultDebugInfoKHR - Structure allowing retrieval of the vendor binary crash dump

Valid Usage (Implicit)

See Also

VK_KHR_device_fault, StructureType, getDeviceFaultDebugInfoKHR

Instances5Extensible, Show, FromCStruct, ToCStruct, Zero

VkDeviceFaultVendorBinaryHeaderVersionOneKHR - Structure describing the layout of the vendor binary crash dump header

Description

Unlike most structures declared by the Vulkan API, all fields of this structure are written with the least significant byte first, regardless of host byte-order.

The C language specification does not define the packing of structure members. This layout assumes tight structure member packing, with members laid out in the order listed in the structure, and the intended size of the structure is 56 bytes. If a compiler produces code that diverges from that pattern, applications must employ another method to set values at the correct offsets.

Valid Usage (Implicit)

See Also

VK_EXT_device_fault, VK_KHR_device_fault, DeviceFaultVendorBinaryHeaderVersionKHR

Constructors

Instances5Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceFaultFeaturesKHR - Structure indicating support for device fault reporting

Members

This structure describes the following features:

Description

In exceptional circumstances, some implementations may mask faults and attempt to recover from an error. In such circumstances, the device is not lost and further work can be submitted to the device. When such faults occur, the contents of all resources being written to at the time of the fault are undefined.

If the PhysicalDeviceFaultFeaturesKHR structure is included in the pNext chain of the PhysicalDeviceFeatures2 structure passed to getPhysicalDeviceFeatures2, it is filled in to indicate whether each corresponding feature is supported. If the application wishes to use a Device with any features described by PhysicalDeviceFaultFeaturesKHR, it must add an instance of the structure, with the desired feature members set to TRUE, to the pNext chain of DeviceCreateInfo when creating the Device.

Structure Chaining

Extends the structures

See Also

VK_KHR_device_fault, Bool32, StructureType

Constructors

  • PhysicalDeviceFaultFeaturesKHR
    • deviceFault :: Bool

      deviceFault indicates that the implementation supports the reporting of device fault information.

    • deviceFaultVendorBinary :: Bool

      deviceFaultVendorBinary indicates that the implementation supports the generation of vendor-specific binary crash dumps. These may provide additional information when imported into vendor-specific external tools.

    • deviceFaultReportMasked :: Bool

      deviceFaultReportMasked indicates that the implementation supports masked faults in normal operation (ie. automatically recovered by the driver internally without the application receiving a ERROR_DEVICE_LOST error) which may be reported via this extension even if they did not result in a ERROR_DEVICE_LOST condition being returned to the application.

    • deviceFaultDeviceLostOnMasked :: Bool

      deviceFaultDeviceLostOnMasked indicates that the implementation supports returning ERROR_DEVICE_LOST for faults that would be normally be masked.

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceFaultPropertiesKHR - Structure describing fault reporting properties for the physical device

Members

The members of the PhysicalDeviceFaultPropertiesKHR structure describe the following:

Description

If the PhysicalDeviceFaultPropertiesKHR structure is included in the pNext chain of the PhysicalDeviceProperties2 structure passed to getPhysicalDeviceProperties2, it is filled in with each corresponding implementation-dependent property.

Structure Chaining

Extends the structure

See Also

VK_KHR_device_fault, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
newtypenewtype DeviceFaultFlagBitsKHR
#

VkDeviceFaultFlagBitsKHR - Bits which may be set in a VkDeviceFaultFlagsKHR bitmask

Description

See Also

VK_KHR_device_fault, DeviceFaultFlagsKHR

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

VkDeviceFaultAddressTypeKHR - Page fault access types

Description

The instruction pointer values recorded may not identify the specific instruction(s) that triggered the fault. The relationship between the instruction pointer reported and triggering instruction will be vendor-specific.

See Also

VK_EXT_device_fault, VK_KHR_device_fault, DeviceFaultAddressInfoKHR

Instances6Eq, Ord, Read, Show, Storable, Zero

VkDeviceFaultVendorBinaryHeaderVersionKHR - Encode vendor binary crash dump version

Description

See Also

VK_EXT_device_fault, VK_KHR_device_fault, DeviceFaultVendorBinaryHeaderVersionOneKHR, getDeviceFaultInfoEXT

Instances6Eq, Ord, Read, Show, Storable, Zero