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_NV_cuda_kernel_launch

Name

VK_NV_cuda_kernel_launch - device extension

VK_NV_cuda_kernel_launch

Name String

VK_NV_cuda_kernel_launch

Extension Type

Device extension

Registered Extension Number

308

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies

VK_KHR_get_physical_device_properties2

or

Vulkan Version 1.1

  • __This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.__

API Interactions
  • Interacts with VK_EXT_debug_report

Contact

Other Extension Metadata

Last Modified Date

2020-09-30

Contributors
  • Eric Werness, NVIDIA

Description

Interoperability between APIs can sometimes create additional overhead depending on the platform used. This extension targets deployment of existing CUDA kernels via Vulkan, with a way to directly upload PTX kernels and dispatch the kernels from Vulkan’s command buffer without the need to use interoperability between the Vulkan and CUDA contexts. However, we do encourage actual development using the native CUDA runtime for the purpose of debugging and profiling.

The application will first have to create a CUDA module using createCudaModuleNV then create the CUDA function entry point with createCudaFunctionNV.

Then in order to dispatch this function, the application will create a command buffer where it will launch the kernel with cmdCudaLaunchKernelNV.

When done, the application will then destroy the function handle, as well as the CUDA module handle with destroyCudaFunctionNV and destroyCudaModuleNV.

To reduce the impact of compilation time, this extension offers the capability to return a binary cache from the PTX that was provided. For this, a first query for the required cache size is made with getCudaModuleCacheNV with a NULL pointer to a buffer and with a valid pointer receiving the size; then another call of the same function with a valid pointer to a buffer to retrieve the data. The resulting cache could then be used later for further runs of this application by sending this cache instead of the PTX code (using the same createCudaModuleNV), thus significantly speeding up the initialization of the CUDA module.

As with PipelineCache, the binary cache depends on the hardware architecture. The application must assume the cache might fail, and need to handle falling back to the original PTX code as necessary. Most often, the cache will succeed if the same GPU driver and architecture is used between the cache generation from PTX and the use of this cache. In the event of a new driver version, or if using a different GPU architecture, the cache is likely to become invalid.

New Object Types

New Commands

New Structures

New Enum Constants

If VK_EXT_debug_report is supported:

Issues

None.

Version History

  • Revision 1, 2020-03-01 (Tristan Lorach)

  • Revision 2, 2020-09-30 (Tristan Lorach)

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.

  • 10 types
  • 8 values
  • Packagevulkan-3.27
  • Exports61
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_NV_cuda_kernel_launch.hs
valuecreateCudaModuleNV
  1. :: MonadIO io
  2. => Device

    device is the logical device that creates the shader module.

  3. -> CudaModuleCreateInfoNV

    pCreateInfo is a pointer to a CudaModuleCreateInfoNV structure.

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

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

  5. -> io CudaModuleNV
#

vkCreateCudaModuleNV - Creates a new CUDA module object

Description

Once a CUDA module has been created, the application may create the function entry point, which must refer to one function in the module.

Valid Usage (Implicit)

  • device must be a valid Device handle

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

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

  • pModule must be a valid pointer to a CudaModuleNV handle

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

Return Codes

Success
Failure

See Also

VK_NV_cuda_kernel_launch, AllocationCallbacks, CudaModuleCreateInfoNV, CudaModuleNV, Device

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

    device is the logical device that destroys the Function.

  3. -> CudaModuleNV

    module is the CUDA module.

  4. -> io (Result, "cacheData" ::: ByteString)
#

vkGetCudaModuleCacheNV - Get CUDA module cache

Description

If pCacheData is NULL, then the size of the binary cache, in bytes, is returned in pCacheSize. Otherwise, pCacheSize must point to a variable set by the application to the size of the buffer, in bytes, pointed to by pCacheData, and on return the variable is overwritten with the amount of data actually written to pCacheData. If pCacheSize is less than the size of the binary shader code, nothing is written to pCacheData, and INCOMPLETE will be returned instead of SUCCESS.

The returned cache may then be used later for further initialization of the CUDA module, by sending this cache instead of the PTX code when using createCudaModuleNV.

Using the binary cache instead of the original PTX code should significantly speed up initialization of the CUDA module, given that the whole compilation and validation will not be necessary.

As with PipelineCache, the binary cache depends on the specific implementation. The application must assume the cache upload might fail in many circumstances and thus may have to get ready for falling back to the original PTX code if necessary. Most often, the cache may succeed if the same device driver and architecture is used between the cache generation from PTX and the use of this cache. In the event of a new driver version or if using a different device architecture, this cache may become invalid.

This query does not behave consistently with the behavior described in Opaque Binary Data Results, for historical reasons.

If the amount of data available is larger than the passed pDataSize, the query returns a INCOMPLETE success status instead of a ERROR_NOT_ENOUGH_SPACE_KHR error status.

Valid Usage (Implicit)

  • device must be a valid Device handle

  • module must be a valid CudaModuleNV handle

  • pCacheSize must be a valid pointer to a size_t value

  • If the value referenced by pCacheSize is not 0, and pCacheData is not NULL, pCacheData must be a valid pointer to an array of pCacheSize bytes

  • module must have been created, allocated, or retrieved from device

Return Codes

Success
Failure

See Also

VK_NV_cuda_kernel_launch, CudaModuleNV, Device

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

    device is the logical device that creates the shader module.

  3. -> CudaFunctionCreateInfoNV

    pCreateInfo is a pointer to a CudaFunctionCreateInfoNV structure.

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

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

  5. -> io CudaFunctionNV
#

vkCreateCudaFunctionNV - Creates a new CUDA function object

Valid Usage (Implicit)

  • device must be a valid Device handle

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

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

  • pFunction must be a valid pointer to a CudaFunctionNV handle

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

Return Codes

Success
Failure

See Also

VK_NV_cuda_kernel_launch, AllocationCallbacks, CudaFunctionCreateInfoNV, CudaFunctionNV, Device

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

    device is the logical device that destroys the shader module.

  3. -> CudaModuleNV

    module is the handle of the CUDA module to destroy.

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

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

  5. -> io ()
#

vkDestroyCudaModuleNV - Destroy a CUDA module

Valid Usage (Implicit)

  • device must be a valid Device handle

  • module must be a valid CudaModuleNV handle

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

  • module must have been created, allocated, or retrieved from device

See Also

VK_NV_cuda_kernel_launch, AllocationCallbacks, CudaModuleNV, Device

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

    device is the logical device that destroys the Function.

  3. -> CudaFunctionNV

    function is the handle of the CUDA function to destroy.

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

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

  5. -> io ()
#

vkDestroyCudaFunctionNV - Destroy a CUDA function

Valid Usage (Implicit)

  • device must be a valid Device handle

  • function must be a valid CudaFunctionNV handle

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

  • function must have been created, allocated, or retrieved from device

See Also

VK_NV_cuda_kernel_launch, AllocationCallbacks, CudaFunctionNV, Device

valuecmdCudaLaunchKernelNV
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> CudaLaunchInfoNV

    pLaunchInfo is a pointer to a CudaLaunchInfoNV structure in which the grid (similar to workgroup) dimension, function handle and related arguments are defined.

  4. -> io ()
#

vkCmdCudaLaunchKernelNV - Dispatch compute work items

Description

When the command is executed, a global workgroup consisting of gridDimX × gridDimY × gridDimZ local workgroups is assembled.

Valid Usage (Implicit)

Host Synchronization

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Both

Outside

VK_QUEUE_COMPUTE_BIT VK_QUEUE_GRAPHICS_BIT

Action

Conditional Rendering

vkCmdCudaLaunchKernelNV is not affected by conditional rendering

See Also

VK_NV_cuda_kernel_launch, CommandBuffer, CudaLaunchInfoNV

VkCudaModuleCreateInfoNV - Structure specifying the parameters to create a CUDA Module

Valid Usage (Implicit)

See Also

VK_NV_cuda_kernel_launch, StructureType, createCudaModuleNV

Constructors

  • CudaModuleCreateInfoNV
    • dataSize :: Word64

      dataSize is the length of the pData array.

      dataSize must be the total size in bytes of the PTX files or binary cache passed to pData

      dataSize must be greater than 0

    • data' :: Ptr ()

      pData is a pointer to CUDA code

      pData must be a valid pointer to an array of dataSize bytes

Instances5Show, Storable, FromCStruct, ToCStruct, Zero

VkCudaFunctionCreateInfoNV - Structure specifying the parameters to create a CUDA Function

Valid Usage (Implicit)

See Also

VK_NV_cuda_kernel_launch, CudaModuleNV, StructureType, createCudaFunctionNV

Constructors

Instances4Show, FromCStruct, ToCStruct, Zero
datadata CudaLaunchInfoNV
#

VkCudaLaunchInfoNV - Structure specifying the parameters to launch a CUDA kernel

Description

Kernel parameters of function are specified via pParams, very much the same way as described in cuLaunchKernel

If function has N parameters, then pParams must be an array of N pointers and paramCount must be N. Each of kernelParams[0] through kernelParams[N-1] must point to a region of memory from which the actual kernel parameter will be copied. The number of kernel parameters and their offsets and sizes are not specified here as that information is stored in the CudaFunctionNV object.

The application-owned memory pointed to by pParams and kernelParams[0] through kernelParams[N-1] are consumed immediately, and may be altered or freed after cmdCudaLaunchKernelNV has returned.

Valid Usage (Implicit)

See Also

VK_NV_cuda_kernel_launch, CudaFunctionNV, StructureType, cmdCudaLaunchKernelNV

Constructors

Instances4Show, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceCudaKernelLaunchFeaturesNV - Structure describing whether cuda kernel launch is supported by the implementation

Members

This structure describes the following features:

Description

If the PhysicalDeviceCudaKernelLaunchFeaturesNV 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 PhysicalDeviceCudaKernelLaunchFeaturesNV, 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_NV_cuda_kernel_launch, Bool32, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceCudaKernelLaunchPropertiesNV - Structure describing the compute capability version available

Members

The members of the PhysicalDeviceCudaKernelLaunchPropertiesNV structure describe the following features:

Description

If the PhysicalDeviceCudaKernelLaunchPropertiesNV 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_NV_cuda_kernel_launch, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
newtypenewtype CudaModuleNV
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
newtypenewtype CudaFunctionNV
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
newtypenewtype DebugReportObjectTypeEXT
#

VkDebugReportObjectTypeEXT - Specify the type of an object handle

Description

'

DebugReportObjectTypeEXT

Vulkan Handle Type

DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT

Unknown/Undefined Handle

DEBUG_REPORT_OBJECT_TYPE_INSTANCE_EXT

Instance

DEBUG_REPORT_OBJECT_TYPE_PHYSICAL_DEVICE_EXT

PhysicalDevice

DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT

Device

DEBUG_REPORT_OBJECT_TYPE_QUEUE_EXT

Queue

DEBUG_REPORT_OBJECT_TYPE_SEMAPHORE_EXT

Semaphore

DEBUG_REPORT_OBJECT_TYPE_COMMAND_BUFFER_EXT

CommandBuffer

DEBUG_REPORT_OBJECT_TYPE_FENCE_EXT

Fence

DEBUG_REPORT_OBJECT_TYPE_DEVICE_MEMORY_EXT

DeviceMemory

DEBUG_REPORT_OBJECT_TYPE_BUFFER_EXT

Buffer

DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT

Image

DEBUG_REPORT_OBJECT_TYPE_EVENT_EXT

Event

DEBUG_REPORT_OBJECT_TYPE_QUERY_POOL_EXT

QueryPool

DEBUG_REPORT_OBJECT_TYPE_BUFFER_VIEW_EXT

BufferView

DEBUG_REPORT_OBJECT_TYPE_IMAGE_VIEW_EXT

ImageView

DEBUG_REPORT_OBJECT_TYPE_SHADER_MODULE_EXT

ShaderModule

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_CACHE_EXT

PipelineCache

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_LAYOUT_EXT

PipelineLayout

DEBUG_REPORT_OBJECT_TYPE_RENDER_PASS_EXT

RenderPass

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_EXT

Pipeline

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT

DescriptorSetLayout

DEBUG_REPORT_OBJECT_TYPE_SAMPLER_EXT

Sampler

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_POOL_EXT

DescriptorPool

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_EXT

DescriptorSet

DEBUG_REPORT_OBJECT_TYPE_FRAMEBUFFER_EXT

Framebuffer

DEBUG_REPORT_OBJECT_TYPE_COMMAND_POOL_EXT

CommandPool

DEBUG_REPORT_OBJECT_TYPE_SURFACE_KHR_EXT

SurfaceKHR

DEBUG_REPORT_OBJECT_TYPE_SWAPCHAIN_KHR_EXT

SwapchainKHR

DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT

DebugReportCallbackEXT

DEBUG_REPORT_OBJECT_TYPE_DISPLAY_KHR_EXT

DisplayKHR

DEBUG_REPORT_OBJECT_TYPE_DISPLAY_MODE_KHR_EXT

DisplayModeKHR

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT

DescriptorUpdateTemplate

DebugReportObjectTypeEXT and Vulkan Handle Relationship

The primary expected use of ERROR_VALIDATION_FAILED_EXT is for validation layer testing to prevent invalid commands from reaching the ICD. It is not expected that an application would see this error code during normal use of the validation layers. If an application returns TRUE in DebugUtilsMessengerCallbackDataEXT, the validation layers will return this error code instead of passing the command down the dispatch chain.

See Also

PFN_vkDebugReportCallbackEXT, VK_EXT_debug_marker, VK_EXT_debug_report, DebugMarkerObjectNameInfoEXT, DebugMarkerObjectTagInfoEXT, debugReportMessageEXT

Instances6Eq, Ord, Read, Show, Storable, Zero