martinsm's picture

OpenCL from AMD

AMD has released beta Stream SDK that includes OpenCL support (currently only with CPU backend):
http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx
Oppurtunity to test out OpenTK bindings for OpenCL.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Includes Linux support - downloading as we speak. Thanks for the heads up!

the Fiddler's picture

First impressions:

  • We seem to be missing a couple functions that are necessary for running OpenCL programs. I'll recreate the OpenCL bindings with the generator, as soon as I manage to fix the parsing of cl.h.
  • Adding those functions by hand, I've converted a few OpenCL samples from C to C#. The current OpenTK.Compute API is rather ugly, but it will come up-to-par with OpenTK.Graphics as soon as the previous task is complete.
  • AMD's SDK does not work on Windows 7 at this point, but seems to work fine on Linux. This will slow down development a bit.

The OpenCL API is rather C-oriented and is relatively difficult to use from C# directly. Higher level wrappers would be much nicer to develop on - anyone interested in helping out?

martinsm's picture

>> AMD's SDK does not work on Windows 7 at this point,

It works fine, if you extract files manually from installer. And add one environment variable: http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=117097

the Fiddler's picture

Thanks for the pointer. Did that, recompiled the project to x86 mode (for some reason the unzipped files are all compiled for x86) and tried to run a sample. It failed on the CL.CreateContextFromType call, throwing a System.EntryPointNotFoundException. I will try again on pure Linux this time.

the Fiddler's picture

I have updated the converter and the generator to work with OpenCL and will commit updated bindings soon.

the Fiddler's picture

Updated binding committed - adding an example.

nythrix's picture
the Fiddler wrote:

The OpenCL API is rather C-oriented and is relatively difficult to use from C# directly. Higher level wrappers would be much nicer to develop on - anyone interested in helping out?

I'have been very interested in giving a hand with the higher level wrapper since you announced OpenCL support. Problem is, I have very little spare time (hour/day max) and all of it is currently going into my own project. Temporarily dropping that I could go for the wrapper. What do you say to one month? Is OpenTK 1.0 expected to provide the wrapper?

P.S.: Should find a name for it.

the Fiddler's picture

A month should be enough to build a usable wrapper (what is it they say about estimates in programming, "multiply by two and raise by an order of magnitude"? :p)

As far as I can tell from the C++ wrapper, the code itself is relatively straightforward (ignoring the moderately heavy template usage). Most methods call the flat API directly and simply check the return values for errors. A few methods contain more complex logic: e.g. they query the number of items, allocate an array and then call the actual function (this mainly affects "get" methods, e.g. GetDevices() or GetSupportedImageFormats() etc).

There are no plans to ship any higher level wrappers as part of OpenTK 1.0. Any such projects are to be developed separately from the core library until they reach a state of maturity.

Now, the first step for an OpenCL wrapper would be to verify the OpenCL bindings work. Once we have a working sample of the flat API (e.g. the OpenCL example in Examples.exe), we can start replacing parts of the sample with higher-level code: context creation, memory allocations, queue management. It will gradually become easier to build more complex examples using the new wrappers (from my experience with OpenGL wrappers, there is an impressive jump in usability once the major pieces start falling into place). The final step is to round out the wrappers with the less commonly-used methods.

OpenCL contains ~65 methods and most are straightforward to use and wrap. In other words, this is not a trivial task but it's not a huge undertaking, either.