Visible to Intel only — GUID: GUID-1ED7AB63-A034-4B01-AC75-C0D7318718DC
Legal Information
Getting Help and Support
Introduction
Check-list for OpenCL™ Optimizations
Tips and Tricks for Kernel Development
Application-Level Optimizations
Debugging OpenCL™ Kernels on Linux* OS
Performance Debugging with Intel® SDK for OpenCL™ Applications
Coding for the Intel® Architecture Processors
Why Optimizing Kernels Is Important?
Avoid Spurious Operations in Kernels
Avoid Handling Edge Conditions in Kernels
Use the Preprocessor for Constants
Prefer (32-bit) Signed Integer Data Types
Prefer Row-Wise Data Accesses
Use Built-In Functions
Avoid Extracting Vector Components
Task-Parallel Programming Model Hints
Common Mistakes in OpenCL™ Applications
Introduction for OpenCL™ Coding on Intel® Architecture Processors
Vectorization Basics for Intel® Architecture Processors
Vectorization: SIMD Processing Within a Work Group
Benefitting from Implicit Vectorization
Vectorizer Knobs
Targeting a Different CPU Architecture
Using Vector Data Types
Writing Kernels to Directly Target the Intel® Architecture Processors
Work-Group Size Considerations
Threading: Achieving Work-Group Level Parallelism
Efficient Data Layout
Using the Blocking Technique
Intel® Turbo Boost Technology Support
Global Memory Size
Visible to Intel only — GUID: GUID-1ED7AB63-A034-4B01-AC75-C0D7318718DC
Conditional Breakpoints on Work Items
According to the OpenCL™ standard, work items are executed concurrently. If a work group contains more than one work item, the debugger stops on a breakpoint in every running work item.
When a kernel is compiled with a -g option, the compiler generates three implicit variables that define the current work item by mapping to global ID within NDRange . Each variable corresponds with one dimension in the three-dimensional NDRange:
- __ocl_dbg_gid0
- __ocl_dbg_gid1
- __ocl_dbg_gid2
You can use these variables to set conditional breakpoints on a specific work item (or work items).
Setting Conditional Breakpoints
To set conditional breakpoints, use the native GDB* or LLDB* commands for conditional breakpoints.
Consider the following example of using conditional breakpoints with the __ocl_dbg_gid0 variable:
- Place a breakpoint at a work item on dimension zero with global ID value equal to two:
(gdb) break kernel.cl:3 if (__ocl_dbg_gid0 == 2)
- Answer yes (y) when you see the following message, because at this moment, a kernel code does not exist, and it will be generated only after you run an application:
Make breakpoint pending on future shared library load? (y or [n]) y
Expected output for this example:
Breakpoint 3 (kernel.cl:3 if (__ocl_dbg_gid0 == 2)) pending.
- Run the application:
(gdb) run
If the application successfully stopped on the breakpoint, you will see the following message with a status of the application and a line where the breakpoint was placed:
[Switching to Thread 0x7fffcffff700 (LWP 26115)] Thread 20 "host_program" hit Breakpoint 1, main_kernel (buf_in=0x1834280 "", buf_out=0x186c880 "") at kernel.cl:3 3 size_t workdim = get_work_dim();
- You can use the __ocl_dbg_gid0 variable to identify a global ID for a specified NDRange dimension. To print the global ID, use the following command:
(gdb) print __ocl_dbg_gid0
Expected output for this example:
$0 = 2