Visible to Intel only — GUID: GUID-7CBC0050-413B-4216-9C4D-6B0F02E49A87
Legal Information
Getting Help and Support
Introduction
Coding for the Intel® Processor Graphics
Platform-Level Considerations
Application-Level Optimizations
Optimizing OpenCL™ Usage with Intel® Processor Graphics
Check-list for OpenCL™ Optimizations
Performance Debugging
Using Multiple OpenCL™ Devices
Coding for the Intel® CPU OpenCL™ Device
OpenCL™ Kernel Development for Intel® CPU OpenCL™ device
Mapping Memory Objects
See Also
Using Buffers and Images Appropriately
Using Floating Point for Calculations
Using Compiler Options for Optimizations
Using Built-In Functions
Loading and Storing Data in Greatest Chunks
Applying Shared Local Memory
Using Specialization in Branching
Considering native_ and half_ Versions of Math Built-Ins
Using the Restrict Qualifier for Kernel Arguments
Avoiding Handling Edge Conditions in Kernels
Using Shared Context for Multiple OpenCL™ Devices
Sharing Resources Efficiently
Synchronization Caveats
Writing to a Shared Resource
Partitioning the Work
Keeping Kernel Sources the Same
Basic Frequency Considerations
Eliminating Device Starvation
Limitations of Shared Context with Respect to Extensions
Why Optimizing Kernel Code Is Important?
Avoid Spurious Operations in Kernel Code
Perform Initialization in a Separate Task
Use Preprocessor for Constants
Use Signed Integer Data Types
Use Row-Wise Data Accesses
Tips for Auto-Vectorization
Local Memory Usage
Avoid Extracting Vector Components
Task-Parallel Programming Model Hints
Visible to Intel only — GUID: GUID-7CBC0050-413B-4216-9C4D-6B0F02E49A87
Mapping Memory Objects
Host code shares physical memory with both OpenCL™ devices: the CPU and the Intel® Graphics. So consider using combination of clEnqueueMapBuffer and clEnqueueUnmapBuffer instead of calls to clEnqueueReadBuffer or clEnqueueWriteBuffer. The recommendation applies to the CPU OpenCL device, Intel Graphics OpenCL device, and also to the shared (CPU and Intel Graphics devices) context.
Notice that there are two ways to ensure zero-copy path on memory objects mapping. The preferred way is to request the OpenCL runtime to allocate memory with CL_MEM_ALLOC_HOST_PTR, so it is originally mirrored on the host in the efficient way.
Another way is to allocate properly aligned and sized memory yourself and share the pointer with the OpenCL framework by using clCreateBuffer with the CL_MEM_USE_HOST_PTR flag. This is a viable option, if your application uses a specific memory management algorithm, or if you want to wrap existing native application memory allocations. The CL_MEM_USE_HOST_PTR flag enables your application to share its memory allocation directly with the OpenCL runtime implementation, and avoid memory copies of the buffer.
For efficiency reasons such a host-side pointer must be allocated for the conditions:
- The amount of memory you allocate and the size of the corresponding OpenCL™ buffer must be multiple of the cache line sizes (64 bytes).
- Always use 4k alignment (page alignment) when you allocate the host memory for sharing with OpenCL devices.
Consider the following pseudo-code example:
int cachelineSize = clGetDeviceInfo(device, …CL_DEVICE_GLOBAL_MEM_CACHELINE);//bytes int arraySizeAligned = cachelineSize*(1+(arraySize-1)/cachelineSize);//aligned void* inputArray = _aligned_malloc(arraySizeAligned, 4096); cl_mem inputBuf = clCreateBuffer(…CL_MEM_USE_HOST_PTR, arraySizeAligned, inputArray);
Similarly, page-align host pointers for the API calls that accept the pointers:
void* dstArray = _aligned_malloc(arraySize, 4096); // example of reading a buffer back from Intel® Graphics device (single-device or shared context), notice that clEnqueueMapBuffer is a better solution clEnqueueReadBuffer(queue, buffer, FALSE, 0, arraySize, dstArray,0, NULL, NULL);
You can map image objects as well. For a context containing only the Intel Graphics device, the mapping of images is less efficient, since the images are tiled and cannot be mapped directly.
You can find additional details in the See Also section below.