Skip to content
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

Add an option in OpenVINOProviderOptions to support the queue-based overload for creating ClContext #19697

Open
fireyoshiqc opened this issue Feb 28, 2024 · 2 comments
Labels
ep:OpenVINO issues related to OpenVINO execution provider stale issues that have not been addressed in a while; categorized by a bot

Comments

@fireyoshiqc
Copy link

fireyoshiqc commented Feb 28, 2024

Currently, the OpenVINO EP only provides a way to share an OpenCL context (for IO Buffering) through a context pointer, given in its provider options (either the struct or string-map based API). It is used in its backend in the following manner:

remote_context_ = new ov::intel_gpu::ocl::ClContext(global_context_.ie_core.Get(), ctx);

This is problematic when wanting to use a specific OpenCL queue instead, as there is no way to do so through the current API, even though OpenVINO itself provides an overload for it (see second constructor):

     /**
     * @brief Constructs context object from user-supplied OpenCL context handle
     * @param core A reference to OpenVINO Runtime Core object
     * @param ctx A OpenCL context to be used to create shared remote context
     * @param ctx_device_id An ID of device to be used from ctx
     */
    ClContext(Core& core, cl_context ctx, int ctx_device_id = 0) {
        AnyMap context_params = {{ov::intel_gpu::context_type.name(), ov::intel_gpu::ContextType::OCL},
                                 {ov::intel_gpu::ocl_context.name(), static_cast<gpu_handle_param>(ctx)},
                                 {ov::intel_gpu::ocl_context_device_id.name(), ctx_device_id}};
        *this = core.create_context(device_name, context_params).as<ClContext>();
    }

    /**
     * @brief Constructs context object from user-supplied OpenCL context handle
     * @param core A reference to OpenVINO Runtime Core object
     * @param queue An OpenCL queue to be used to create shared remote context. Queue will be reused inside the plugin.
     * @note Only latency mode is supported for such context sharing case.
     */
    ClContext(Core& core, cl_command_queue queue) {
        cl_context ctx;
        auto res = clGetCommandQueueInfo(queue, CL_QUEUE_CONTEXT, sizeof(cl_context), &ctx, nullptr);
        OPENVINO_ASSERT(res == CL_SUCCESS, "Can't get context from given opencl queue");
        AnyMap context_params = {{ov::intel_gpu::context_type.name(), ov::intel_gpu::ContextType::OCL},
                                 {ov::intel_gpu::ocl_context.name(), static_cast<gpu_handle_param>(ctx)},
                                 {ov::intel_gpu::ocl_queue.name(), static_cast<gpu_handle_param>(queue)}};
        *this = core.create_context(device_name, context_params).as<ClContext>();
    }

The API should be adapted to allow specifying an OpenCL queue, instead of only a context, calling the second CLContext constructor in that case.

Urgency
Fixed it on my end, but would like to upstream.

Platform
Windows

OS Version
11

ONNX Runtime Installation
Released Package

ONNX Runtime Version or Commit ID
1.17.1

ONNX Runtime API
C++

Architecture
X64

Execution Provider
OpenVINO EP GPU

Execution Provider Library Version
5.1?

@jywu-msft
Copy link
Member

+@sfatimar , @preetha-intel FYI

Copy link
Contributor

This issue has been automatically marked as stale due to inactivity and will be closed in 30 days if no further activity occurs. If further support is needed, please provide an update and/or more details.

@github-actions github-actions bot added the stale issues that have not been addressed in a while; categorized by a bot label Mar 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ep:OpenVINO issues related to OpenVINO execution provider stale issues that have not been addressed in a while; categorized by a bot
Projects
None yet
Development

No branches or pull requests

3 participants