-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Adding CIG context creation in OrtFactory #27267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1020,6 +1020,74 @@ typedef struct OrtExternalSemaphoreDescriptor { | |
| void* native_handle; /**< Platform-specific handle (e.g., Windows HANDLE) */ | ||
| } OrtExternalSemaphoreDescriptor; | ||
|
|
||
| /** \brief Graphics API type for interop configuration. | ||
| * | ||
| * Specifies the graphics API used for GPU interop with the execution provider. | ||
| * This enables synchronization between graphics workloads (e.g., rendering, compute shaders) | ||
| * and ONNX Runtime inference. | ||
| * | ||
| * \since Version 1.25. | ||
| */ | ||
| typedef enum OrtGraphicsApi { | ||
| ORT_GRAPHICS_API_NONE = 0, /**< No graphics interop (default) */ | ||
| ORT_GRAPHICS_API_D3D12 = 1, /**< Direct3D 12 interop */ | ||
| ORT_GRAPHICS_API_VULKAN = 2, /**< Vulkan interop */ | ||
| } OrtGraphicsApi; | ||
|
|
||
| /** \brief Configuration for initializing graphics interop on an EP factory. | ||
| * | ||
| * This structure contains all parameters needed to set up graphics interop between | ||
| * ONNX Runtime and an external graphics API (D3D12, Vulkan). The factory stores this | ||
| * configuration and uses it when creating synchronization streams. | ||
| * | ||
| * Design rationale (following Scott McKay's suggestions): | ||
| * - Single init function with all required params to avoid multiple init signatures | ||
| * - Factory stores the context and uses it in stream creation | ||
| * - Supports extensibility via additional_options for future requirements | ||
| * | ||
| * Example usage for D3D12: | ||
| * \code | ||
| * OrtGraphicsInteropConfig config = {0}; | ||
| * config.version = ORT_API_VERSION; | ||
| * config.graphics_api = ORT_GRAPHICS_API_D3D12; | ||
| * config.command_queue = my_d3d12_command_queue; // ID3D12CommandQueue* | ||
| * config.device = my_d3d12_device; // ID3D12Device* (optional) | ||
| * status = ep_factory->InitGraphicsInterop(ep_factory, ep_device, &config); | ||
| * \endcode | ||
| * | ||
| * \note The version field must be set to ORT_API_VERSION. | ||
| * This ensures forward compatibility as fields may be added in future versions. | ||
| * | ||
| * \since Version 1.25. | ||
| */ | ||
| typedef struct OrtGraphicsInteropConfig { | ||
| uint32_t version; /**< Must be ORT_API_VERSION */ | ||
| OrtGraphicsApi graphics_api; /**< The graphics API to use for interop */ | ||
|
|
||
| /** \brief Command queue/submission queue for graphics workloads. | ||
| * | ||
| * For D3D12: ID3D12CommandQueue* | ||
| * For Vulkan: VkQueue (cast to void*) | ||
| * | ||
| * The factory stores this and uses it for synchronization with inference streams. | ||
| */ | ||
| void* command_queue; | ||
|
|
||
| /** \brief Graphics device handle (optional, may be inferred from command_queue). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We shouldn't absolutely require a command_queue either right? That is more of a performance optimization. This config shouldn't be required for the InteropApi to work |
||
| * | ||
| * For D3D12: ID3D12Device* (optional, can be obtained from command queue) | ||
| * For Vulkan: VkDevice (cast to void*) | ||
| */ | ||
| void* device; | ||
|
Comment on lines
+1076
to
+1081
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can the device be retrieved using info from the OrtEpDevice or does it need to be passed in? Prefer the former as there's no potential mismatch. |
||
|
|
||
| /** \brief Additional API-specific options (optional). | ||
| * | ||
| * Can be used for future extensibility without changing the struct layout. | ||
| * For example, Vulkan-specific queue family index, or D3D12 fence sharing flags. | ||
| */ | ||
| const OrtKeyValuePairs* additional_options; | ||
| } OrtGraphicsInteropConfig; | ||
|
|
||
| /** \brief Descriptor for creating a tensor from imported external memory. | ||
| * | ||
| * \note The version field must be set to ORT_API_VERSION. | ||
|
|
@@ -7242,6 +7310,38 @@ struct OrtApi { | |
| * \since Version 1.25. | ||
| */ | ||
| ORT_API2_STATUS(RunOptionsDisableProfiling, _Inout_ OrtRunOptions* options); | ||
|
|
||
| /** \brief Initialize graphics interop for an execution provider device. | ||
| * | ||
| * This function enables D3D12/Vulkan interoperability by creating a graphics interop context | ||
| * bound to the provided graphics command queue. Once initialized, any OrtSyncStream created for this | ||
| * ep_device via CreateSyncStreamForEpDevice will be created on the interop context, enabling efficient | ||
| * GPU-side synchronization between ONNX Runtime inference and graphics workloads. | ||
| * | ||
| * This must be called BEFORE CreateSyncStreamForEpDevice for the same ep_device. | ||
|
Comment on lines
+7317
to
+7321
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These seem like they're potentially implementation specific details. Isn't it up to the EP factory what it does in the init and how that affects later calls? Would also be good to explicitly call out that as this is tied to the OrtEpDevice instance it applies across all sessions the OrtEpDevice is used in (i.e. it's global not per-session). |
||
| * | ||
| * \param[in] ep_device The OrtEpDevice to initialize graphics interop for. | ||
| * \param[in] config Configuration specifying the graphics API (D3D12/Vulkan) and required handles. | ||
| * | ||
| * \snippet{doc} snippets.dox OrtStatus Return Value | ||
| * | ||
| * \since Version 1.25. | ||
| */ | ||
| ORT_API2_STATUS(InitGraphicsInteropForEpDevice, _In_ const OrtEpDevice* ep_device, | ||
| _In_ const OrtGraphicsInteropConfig* config); | ||
|
Comment on lines
+7330
to
+7331
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we please add these two functions to the interop API struct instead of the global ORT API so we keep all the interop related pieces in one place?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, could this be a configuration that is "applied to" an OrtEpDevice's InteropApi? Rather than it being an independent thing. I'm not sure we really need to qualify it as "Graphics" either, that is a bit more domain specific than this would afford. |
||
|
|
||
| /** \brief Deinitialize graphics interop for an execution provider device. | ||
| * | ||
| * This function cleans up the graphics interop context that was created by InitGraphicsInteropForEpDevice. | ||
| * Should be called when graphics interop is no longer needed for the ep_device. | ||
| * | ||
| * \param[in] ep_device The OrtEpDevice to deinitialize graphics interop for. | ||
| * | ||
| * \snippet{doc} snippets.dox OrtStatus Return Value | ||
| * | ||
| * \since Version 1.25. | ||
| */ | ||
| ORT_API2_STATUS(DeinitGraphicsInteropForEpDevice, _In_ const OrtEpDevice* ep_device); | ||
| }; | ||
|
|
||
| /* | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: factory can do whatever it wants so I would expect storing or not is an implementation detail and not a requirement.