I have some OpenCL kernels that aren't doing what they should be, and I would love to debug them in Xcode. Is this possible?
If not, is there any way I can use printf() in my CPU-based kernels? When I use printf() in my kernels the OpenCL compiler always gives me a whole bunch of errors.
Casting the format string to const char * appears to fix this problem.
This works for me on Lion:
printf((char const *)"%d %d\n", dl, dll);
This has the error described above:
printf("%d %d\n", dl, dll);
Have you tried adding this pragma to enable printf?
#pragma OPENCL EXTENSION cl_amd_printf : enable
You might also want to try using Quartz Composer to test out your kernels. If you have access to the WWDC 2010 videos, I believe they show how to use Quartz Composer for rapid prototyping of OpenCL kernels in Sessions 416: "Harnessing OpenCL in Your Application" or 418: "Maximizing OpenCL Performance". There were also some good sessions on this during WWDC 2009 and 2008 that might also be available via ADC on iTunes.
Using Quartz Composer, you can quickly set up inputs and outputs for a kernel, then monitor the results in realtime. You can avoid the change-compile-test cycle because everything is compiled as you type. Syntax errors and the like will pop up as you change code, which makes it fairly easy to identify those.
I've used this tool to develop and test out OpenGL shaders, which have many things in common with OpenCL kernels.
Have you given the gDEBugger a try already? I think it's the only choice you have currently, for OpenCL debugging on the Mac.
Intel offers a printf in their new OpenCL 1.1 SDK, but that's only for Linux and Windows. Lion has OpenCL 1.1, but at least my Core 2 Duo does not support the printf extension.
AMD ist still developing their OpenCL tools, and the Nvidia Debugging tools are only for CUDA, as far as I understand.
Related
I consider using OpenCL in a consumer product which is currently under development.
Doing a small research I found that generally there is good support under Mac OSX. Linux support is also relatively good, but my target audience does not use Linux. It remains to check how well it is supported in Windows.
Regarding Windows I found OpenCL distribution which raises some concerns.
Do any of you have any experience with using OpenCL in consumer-oriented products under Windows? I am more interested in the GPU side of OpenCL, specifically driver support.
Just like CUDA or Stream, OpenCL needs to be supported by the driver. Most CUDA-capable GPUs support OpenCL with a somewhat up-to-date driver (CUDA 1.0 upwards).
In fact, if you compile with, say, CUDA SDK 4.1 your end users will need newer drivers than if you had used OpenCL.
Also, OpenCL is not bound to any GPU architecture. While this might be problematic for specifically designed algorithms, it shouldn't have a very high impact on normal end user programs.
At least with CUDA, you can only compile code optimized for the current known major version. Compiling OpenCL kernels on the end user machine might allow optimizations for newer binary specifications in the future.
The crashes the author in that questions reported for Nvidia OpenCL generally seem to happen a lot if resources are not freed properly. I've been seeing similar crashes until I fixed a leak that didn't release created kernels.
I'm not saying it's the only reason why it might crash, but apart from programmer errors it appears fairly stable to me.
AMD and NVidia both support OpenCL on most (all?) of their GPUs
Unfortunately Intel only supports it on the CPU which is a bit pointless and if you have to insist that the user has a separate GPU for your app you can also insist that they have an NVidia one and use CUDA. This has limited the uptake of OpenCL.
I was just looking through the OpenGL updates on OS X Lion when I found something that now has me scared to use glext.h.
So, here's the bug. Lion's OpenGL.framework has a glext.h with the following definition.
typedef void *GLhandleARB;
But the glext.h from the OpenGL registry has the following instead.
typedef unsigned int GLhandleARB;
Now, the trouble is that when building for x86_64 on Lion we have sizeof(void*)==8, but sizeof(unsigned int)==4. So what do you trust? Lion's header? Or the OpenGL registry's header? Well, of course you trust the system headers, because apparently they claim to know that the ABI on 64-bit Lion has a 64-bit GLhandleARB type.
Now, this raises a few issues in my mind about various platforms:
If you must use Apple's glext.h, but Apple's glext.h doesn't provide access to anything later than OpenGL 2.1, then how do you get at 3.0+ features on newer cards?
Is it unsafe to use the OpenGL registry's glext.h on Linux? Or must you use the system's glext.h there as well? In that case, question #1 applies here as well.
How the heck do you handle things on Windows, where there is never a glext.h on the system? You clearly can't use a driver vendor's glext.h, because different vendors may disagree on the sizes of various types. (Or is that not true?) What's the deal here?
I see no problem.
Just use OS/drivers provided headers.
Or better use multi-platform OpenGL extension loader, that will do the trick for you.
(eg. GLEW)
On the other hand in code you will use only GLhandleARB, not other things, so on Mac it will be void* - no problem, on Linux - something different - no problem, on Linux with AMD header - something entirely different - no problem.
Source code is portable across different platforms, not binaries, so I see no problem here.
1) You cant get better OpenGL if you use version served by Apple. So currently you can get max OpenGL 3.2 core profile on 10.7. (heard that Nvidia on some gpus bypassed it with its own headers with OpenGL 3.3, but have no way to check it myself).
2) It depends. If you target OpenGL 2.1 and below, open-source drivers support it, but higher versions are supported only by proprietary drivers, so you should use their headers.
But in code you just put "#include ", and then link against appropriate header and .so library.
3) Do not know how things stand on Win. But probably vendors use glext from OpenGL registry.
But all of this is based on wrong assumption. You DO NOT have to know answers for them. Just use software that already know how to handle this burden. (eg. GLEW).
You should use the official OpenGL function to get the extensions supported by the instance of OpenGL you are running with: glGetString(GL_EXTENSIONS)
As for which type you should use, I think this has already been answered Apple's mailing lists: http://lists.apple.com/archives/mac-opengl/2005/Nov/msg00182.html
Both; the spec doesn't make any claims about what a GLhandleARB is,
other than that it's at least 32 bits wide. Note that in the OpenGL
2.0 shading language API there is no GLhandle type, it uses GLuint
like textures. Also note that GLuint is not an unsigned int on Mac OS
X, it's an unsigned long, so you're still screwed :)
I'm little confuse with NVIDIA Parallel Nsight and OpenCL, can anyone confirm me that it is possible to debug OpenCL code using NVIDIA Parallel Nsight 1.5 or 2.0RC?
Currently it is not possible to debug OpenCL kernels with Parallel Nsight yet. Parallel Nsight 2.0 (the latest release as of Jun 2011) only supports the debugging of CUDA kernel. However OpenCL debugging is one of the features that is likely to go into the product in future releases.
Yes, it is possible, I've did it my self, the only problem is that you will need two computers connected to network, having two identical video cards. One will be executing your kernel step by step(due to this fact the graphical adapter won't be able to display results, the display will stall) this is where the second computer comes in to play, it displays results in Visual Studio like you were debugging ordinary program.
Personally I found NVIDIA Parallel Nsight as a useless tool. Any kernel debugging can be done via adding additional argument to a kernel and outputting any subject data there.
Parallel Nsight 2.1 include API for trace OpenCL 1.1 now
#see http://nvidia.com/object/parallel-nsight.html
How can I know which CPU can be programmed by OpenCL?
For example, the Pentium E5200.
Is there a way to know w/o running and querying it?
OpenCL compatibility can generally be determined by looking on the vendor's sites. AMD's APP SDK requires CPUs to support at least SSE2. They also have a list of currently supported ATI/AMD video cards.
The most official source is probably the Khronos conformance list:
http://www.khronos.org/conformance/adopters/conformant-products#opencl
For compatibility with the AMD APP SDK: http://developer.amd.com/gpu/AMDAPPSDK/pages/DriverCompatibility.aspx
For the NVIDIA, anything that supports CUDA should support their implementation of OpenCL:
http://www.nvidia.com/object/cuda_gpus.html
For compatibility with the Intel OpenCL SDK, look at:
https://software.intel.com/en-us/articles/opencl-code-builder-release-notes
Here is the list of conforming OpenCL products from the Khronos site:
http://www.khronos.org/conformance/adopters/conformant-products/
You got Intel OpenCL too http://software.intel.com/en-us/articles/intel-opencl-sdk/ for windows right now.
Just one more comment about Intel, Now they do not only support OpenCL under windows, but also linux. But it is part of a commercial SDK see https://software.intel.com/en-us/intel-media-server-studio.
Another alternative for OpenCL development under Linux is Beignet, an OpenCL source project maintain by Intel China.
http://www.freedesktop.org/wiki/Software/Beignet/
I have tested on linux and it works as per tutorial, however, the compiler they use is completely different from the one under the windows.
Well for the CPU, AMD's SDK is supposed to work on x86 (even on Intel's x86), so that will cover most of your options.
And for the GPU, I think almost all cards made in the last couple of years should run OpenCL kernels. I don't have of a particular list.
EDIT: Looks like AMD removed the original SDK pages with no replacement. There are unofficial mirrors for Windows and Linux, but I haven't tried them.
I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.