[GPU] Support CPU pointers on remote tensor#36539
Conversation
| auto tracker = std::make_shared<MemoryTracker>(this, | ||
| cpu_address, | ||
| data_size, | ||
| allocation); |
There was a problem hiding this comment.
Should this memory tracker be created? I guess there is no additional allocation when CL_MEM_FORCE_HOST_MEMORY_INTEL is used?
There was a problem hiding this comment.
tracker is needed in some places in code, constructed without engine not add allocation to statistic
There was a problem hiding this comment.
should be same pattern made in case of NTHandle ?
There was a problem hiding this comment.
Yes, I think we should only track OpenVINO allocations and do not count memory allocated by the user.
jkoniusz
left a comment
There was a problem hiding this comment.
Maybe this is gonna be of some use to you:
The checks are failing because (I checked build_win_vs2022_release log):
"
[2026-07-08T09:07:41.198Z] C:\Jenkins\workspace\private-ci\ie\build-windows-vs2022\b\repos\openvino\src\plugins\intel_gpu\tests\functional\remote_tensor_tests\dx11_nthandle.cpp(252): error C3861: 'SharedBufferHandle': identifier not found
[2026-07-08T09:07:41.199Z] C:\Jenkins\workspace\private-ci\ie\build-windows-vs2022\b\repos\openvino\src\plugins\intel_gpu\tests\functional\remote_tensor_tests\dx11_nthandle.cpp(250): error C2668: 'ov::intel_gpu::ocl::ClContext::create_tensor': ambiguous call to overloaded function
"
Theres compile error
Allegedly now dx11_nthandle.cpp / dx12_nthandle.cpp still reference a SharedBufferHandle symbol.
SharedBufferHandle isn't a valid/visible name in those files — either it was never namespace-qualified (ov::intel_gpu::ocl::SharedBufferHandle), or it got renamed/removed when you refactored API.
Because that argument doesn't resolve, the create_tensor(...) call can't pick an overload → error C2668: ambiguous call.
probably need add ov::intel_gpu:: before SharedBufferHandle |
| createHeap(byte_size); | ||
|
|
||
| auto remote_tensor = context.create_tensor(ov::element::f32, tensor.get_shape(), shared_mem, ov::intel_gpu::MemType::SHARED_BUF); | ||
| auto remote_tensor = context.create_tensor(ov::element::f32, tensor.get_shape(), SharedBufferHandle(shared_mem)); |
| #ifdef CL_MEM_FORCE_HOST_MEMORY_INTEL | ||
| const size_t minimal_alignment = static_cast<size_t>(get_device_info().cacheline_size); | ||
| OPENVINO_ASSERT((reinterpret_cast<std::uintptr_t>(cpu_address) % minimal_alignment) == 0, | ||
| "[GPU] shared buffer pointer must be ", minimal_alignment, "-byte aligned"); | ||
| OPENVINO_ASSERT((data_size % minimal_alignment) == 0, | ||
| "[GPU] shared buffer size must be a multiple of ", minimal_alignment, " bytes"); | ||
| flags |= CL_MEM_FORCE_HOST_MEMORY_INTEL; | ||
| #endif |
There was a problem hiding this comment.
I would prefer 1 additional check over risking undefined behavior. Even if we expect that cacheline_size is more than 0.
| std::shared_ptr<MemoryTracker> tracker = nullptr; | ||
| #ifdef CL_MEM_FORCE_HOST_MEMORY_INTEL | ||
| tracker = std::make_shared<MemoryTracker>(nullptr, | ||
| cpu_address, | ||
| data_size, | ||
| allocation); | ||
| #else | ||
| tracker = std::make_shared<MemoryTracker>(this, | ||
| cpu_address, | ||
| data_size, | ||
| allocation); | ||
| #endif |
There was a problem hiding this comment.
this is my intention to not count this in statistic
| uint32_t cacheline_size = core.get_property(target_device, ov::intel_gpu::cacheline_size); | ||
| const size_t float_size = sizeof(float); | ||
| const ov::Shape shape{cacheline_size/float_size}; | ||
| const size_t element_count = ov::shape_size(shape); | ||
| const size_t byte_size = element_count * sizeof(float); | ||
| auto ctx = core.get_default_context(target_device).as<ov::intel_gpu::ocl::ClContext>(); | ||
| void* input_ptr = ov::util::aligned_alloc(byte_size, byte_size); | ||
| void* output_ptr = ov::util::aligned_alloc(byte_size, byte_size); |
There was a problem hiding this comment.
partially applied, proposed change: const ov::Shape shape{static_cast<size_t>(cacheline_size)}; not check bound case
Typo was fixed. So, I dismiss review to respect @isanghao time zone. I will put my approve
d64394f
#### Details: Description of the issue (symptom, root-cause, how it was resolved) - Zero-copy handling for `usm_host` and `usm_shared` was already implemented in earlier PRs (openvinotoolkit#34494, openvinotoolkit#36539); this PR focuses on closing the `usm_device` gap. - Previously, for `usm_device` allocations, a separate GPU `usm_device` buffer was allocated and filled from mapped host buffer data during cache load, causing duplicate allocation/copy overhead and increasing inference memory footprint. - This change enables zero-copy subbuffer usage for supported XE2+ iGPUs in the `usm_device` flow, removing extra staging/copy in applicable cases. - Blob offset alignment handling in deserialization is kept correct for subbuffer creation. Implementation changes: - Extend zero-copy eligibility in `data.hpp` to include `usm_device` while preserving existing `usm_host`/`usm_shared` behavior. - Add/use helper check for zero-copy-capable device (XE2+ integrated GPU). - Use `seek_current_ptr()` for padding skip during deserialization alignment. - Refine zero-copy condition naming/readability in load path. Changed files: src/plugins/intel_gpu/include/intel_gpu/graph/serialization/binary_buffer.hpp src/plugins/intel_gpu/include/intel_gpu/primitives/data.hpp src/plugins/intel_gpu/include/intel_gpu/runtime/device_info.hpp src/plugins/intel_gpu/src/graph/program.cpp src/plugins/intel_gpu/src/runtime/ocl/ocl_device.cpp src/plugins/intel_gpu/src/runtime/ocl/ocl_engine.cpp src/plugins/intel_gpu/tests/unit/test_cases/cache_serialization_test.cpp Reproduction step and snapshot (if applicable. Do not attach for customer model) NA Problematic graph NA #### Checklist - [x] Is it a proper fix? Yes (removes duplicate `usm_device` staging/copy in supported zero-copy cases) - [x] Did you include test case for this fix, if necessary? NA - [x] Did you review existing test that can be extended to cover this scenario? NA #### Tickets: - CVS-176160 #### AI Assistance: - AI assistance used: yes - AI was used for wording refinement and commit message cleanup.
#### Details: Description of the issue (symptom, root-cause, how it was resolved) - Zero-copy handling for `usm_host` and `usm_shared` was already implemented in earlier PRs (openvinotoolkit#34494, openvinotoolkit#36539); this PR focuses on closing the `usm_device` gap. - Previously, for `usm_device` allocations, a separate GPU `usm_device` buffer was allocated and filled from mapped host buffer data during cache load, causing duplicate allocation/copy overhead and increasing inference memory footprint. - This change enables zero-copy subbuffer usage for supported XE2+ iGPUs in the `usm_device` flow, removing extra staging/copy in applicable cases. - Blob offset alignment handling in deserialization is kept correct for subbuffer creation. Implementation changes: - Extend zero-copy eligibility in `data.hpp` to include `usm_device` while preserving existing `usm_host`/`usm_shared` behavior. - Add/use helper check for zero-copy-capable device (XE2+ integrated GPU). - Use `seek_current_ptr()` for padding skip during deserialization alignment. - Refine zero-copy condition naming/readability in load path. Changed files: src/plugins/intel_gpu/include/intel_gpu/graph/serialization/binary_buffer.hpp src/plugins/intel_gpu/include/intel_gpu/primitives/data.hpp src/plugins/intel_gpu/include/intel_gpu/runtime/device_info.hpp src/plugins/intel_gpu/src/graph/program.cpp src/plugins/intel_gpu/src/runtime/ocl/ocl_device.cpp src/plugins/intel_gpu/src/runtime/ocl/ocl_engine.cpp src/plugins/intel_gpu/tests/unit/test_cases/cache_serialization_test.cpp Reproduction step and snapshot (if applicable. Do not attach for customer model) NA Problematic graph NA #### Checklist - [x] Is it a proper fix? Yes (removes duplicate `usm_device` staging/copy in supported zero-copy cases) - [x] Did you include test case for this fix, if necessary? NA - [x] Did you review existing test that can be extended to cover this scenario? NA #### Tickets: - CVS-176160 #### AI Assistance: - AI assistance used: yes - AI was used for wording refinement and commit message cleanup.
Details:
Tickets: