OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1663 Discussions

Some questions on new OpenCL GPU support..

Have same questions about new GPU support..

first seems with jointly CPU+GPU context graphics interop via all apis is disabled (gl and d3d10 interop) this isn't the case with amd ocl sdk either in fusion or cpu+gpu discrete case.. why that limitation? I'm assuming you are allowing creation of buffers and textures in same special memory region where zero copy usage of this buffers is possible either in CPU or GPU.. but seems these are is not good for direct usage in GPU by graphics APIs is that the case?.. more info please.. at least would be good to add support of graphics apis interop in cpu+gpu context but says in that case says that buffers or texture acquired via clcreatefromGLbuffer aren't zero copy if used by CPU kernels, no?
second questions in graphics interop table you say that d3d10 interop is truly zero copy if using RESOURCE_MISC_SHARED but seems in OpenGL is no way of assuring that we have zero copy usage.. why that? could you clarify how to check if gl buffer or texture is efficiently mapped to gpu kernels?more info please.
0 Kudos
1 Reply


Right; GL/DX interoperability on all it's flavors isn't supported at CPU+GPU context (aka Shared Context)

This is a known issue; being evaludated for introduction at future versions;

We are very interested in getting an idea about what kind of usage you are seeking here with interop at Shared Context, can u please elaborate a little bit what usage is it targetting?

Resource Sharing

Right, resources as buffers/textures are phsyically shared by the context devices, CPU+GPU, in a Shared Context; Please note that u need to gauarantee alignments requirement according to the optimization guide for assuring physical sharing with the user hostptr (in case of CL_MEM_USE_HOST_PTR) in case its being provided.

This is doesn't necessarily mean that textures targetting GPU are managed less efficient comparing to single GPU context; Please notice that in case you have used hostptr at the texture creation which is aligned to 4K (see Intel OpenCL Optimization Guide) at Shared Context, then you have increased performance at clEnqueueMap/Unmap for the same texture.