work_dim - the number of measurements to perform clEnqueueNDRangeKernel() .
If you specify work_dim = 1 , then global and job sizes will be one-dimensional . Thus, inside the kernels you can only access information in the first dimension , for example. get_global_id(0) etc.
If you specify work_dim = 2 or 3 , you must also specify 2 or 3D global and local jobs ; in this case, you can access information inside the cores in 2 or 3 dimensions , for example. get_global_id(1) or get_group_id(2) .
In practice, you can do everything in 1D , but for working with 2D or 3D data it is probably easier to use 2/3 dimensional cores ; for example, in the case of 2D data, such as an image, if each thread / work item needs to process one pixel, each thread / work item can deal with a pixel in coordinates (x,y) , with x = get_global_id(0) and y = get_global_id(1) .
A work item is a thread , and workgroups are work item / thread groups . >.
I believe that work groups / work elements of separation are related to the hardware architecture of GPUs and other accelerators (for example, Cell / BE); you can match the execution of workgroups with Stream Multiprocessors GPUs (in NVIDIA conversations) or SPUs (in IBM / Cell conversations), while the corresponding workflows will be performed inside Stream MultiProcessors and / or SPU execution units. It is not uncommon to have work group size = 1 if you run cores in the CPU (for example, for a quad core, you will have 4 work groups, each of which has one work item), although in my experience it is usually better to have more work groups than CPU cores).
Check out the OpenCL reference guide as well as the OpenCl guide for any device you're programming.
faken source share