For the most part we will not concern ourselves with recovering from an error; for simplicity, we define a function, checkErr , to see that a certain call has completed successfully. If it is not, it outputs a user message and exits; otherwise, it simply returns. But before we can create a context we must first queue the OpenCL runtime to determine which platforms, i.
The class cl::Platform provides the static method cl::Platform::get for this and returns a list of platforms. For now we select the first platform and use this to create a context. For example, buffers 1D regions of memory and images 2D and 3D regions of memory allocation are all context operations.
But there are also device specific operations. For example, program compilation and kernel execution are on a per device basis, and for these a specific device handle is required. So how do we obtain a handle for a device? We simply query a context for it. In the specific case of getting the device from a context:. Now that we have the list of associated devices for a context, in this case a single CPU device, we need to load and build the compute program the program we intend to run on the device, or more generally: devices.
Given an object of type cl::Program::Sources a cl::Program , an object is created and associated with a context, then built for a particular set of devices. A given program can have many entry points, called kernels, and to call one we must build a kernel object. In this case we can build a cl::kernel object, kernel. All device computations are done using a command queue, which is a virtual interface for the device in question.
Each command queue has a one-to-one mapping with a given device; it is created with the associated context using a call to the constructor for the class cl::CommandQueue. Given a cl::CommandQueue queue , kernels can be queued using queue.
This queues a kernel for execution on the associated device. The kernel can be executed on a 1D, 2D, or 3D domain of indexes that execute in parallel, given enough resources. The total number of elements indexes in the launch domain is called the global work size; individual elements are known as work-items.
Work-items can be grouped into work-groups when communication between work-items is required. Work-groups are defined with a sub-index function called the local work size , describing the size in each dimension corresponding to the dimensions specified for the global launch domain.
There is a lot to consider with respect to kernel launches, and we will cover this in more detail in future tutorials. For now, it is enough to note that for Hello World, each work-item computes a letter in the resulting string; and it is enough to launch hw. We need the extra work-item to account for the NULL terminator. The final argument to the enqueueNDRangeKernel call above was a cl::Event object, which can be used to query the status of the command with which it is associated, for example, it has completed.
It supports the method wait that blocks until the command has completed. This is required to ensure the kernel has finished execution before reading the result back into host memory with queue.
With the compute result back in host memory, it is simply a matter of outputting the result to stdout and exiting the program. For robustness, it would make sense to check that the thread id tid is not out of range of the hw; for now, we assume that the corresponding call to queue.
Your feedback, comments, and questions are requested. Please visit our Stream forum. I have not tested these and cannot vouch for their correctness, but hope they will be useful:. This article, along with any associated source code and files, is licensed under The Apache License, Version 2. Sign in Email. Forgot your password? Search within: Articles Quick Answers Messages. Tagged as All-Topics. Stats Please Sign up or sign in to vote. Once installation and basic implementation is done, only simple changes in a kernel string or its file applies an algorithm to N hardware threads automagically.
A developer might want to use it because it will be much easier to optimize for memory space or speed than doing same thing on opengl or direct-x. Also it is royalty-free. Concurrency within a device is implicit so no need for explicit multi-threading for each device. But for multi-device configurations, a cpu-multi-threading is still needed. For example, when a threaded job is sent to a cpu, thread synchronization is handled by driver.
You just tell it how big a workgroup should be such as each connected with virtual local memory and where synchronization points are only when needed. Using gpu for general purpose operations is nearly always faster than cpu. You can sort things quicker, multiply matrices 10x faster and left join in-memory sql tables in "no" time. Opencl makes it easier and portable. For the graphics part, you are not always have to send buffers between cpu and gpu.
You can work purely on gpu using "interop" option in context creation part. With interop, you can prepare geometries at the limit performance of gpu. No pci-e required for any vertex data. Just a "command" is sent through, and work is done only inside of graphics card.
This means no cpu-overhead for data. Opencl prepares geometry data, opengl renders it. CPU becomes released. For example, if a single thread of cpu can build a 32x32 verticed sphere in cycles, then a gpu with opencl can build 20 spheres in cycles.
OpenCL is low level api so it must be implemented in "C space" first.
0コメント