I just published my version of .NET bindings for OpenCL over on Codeplex last night. Why another, you ask? There’s already so many out there … Cloo, OpenCL.NET from hoopoe and another OpenCL.Net over at Sourceforge (and more?). Well, …

• Every API out there has an object-oriented version of the API that’s easily usable from .NET. Sure, it’s easy … but looks very different from the raw OpenCL API if I wanted to use it, right? There’s reason #1 right there. I wanted a set of .NET bindings that look, feel and act like the C-style API so I (read: the users) could port existing samples or read books/tutorials and understand what’s going on.
• Which brings us to our second question: Don’t all of the mentioned bindings also have the C-style API exposed? Sure, they do. But some of them mark the exposed API as unsafe, use of which would force users to mark their own projects as unsafe too. Secondly, every set of bindings I saw had raw translations of the API transliterating <anything>* to IntPtr (and others along those lines) meaning we have to use their OO abstractions to get anything done easily. I wanted something more .NET friendly at the API level, however.

So I guess the reason I wrote my own bindings is: I wanted to strike the middle ground between OO + .NET friendly and raw API translation. You can find this over at Codeplex. The API isn’t complete yet, but some things I’m particularly happy about are:

1. No unsafe code (yet).
2. Everything is .NET friendly AND you can use it as you would the raw API (overloads).
3. As little explicit marshaling as possible, in fact all the exposed methods that invoke the extern’d methods in OpenCL.dll are only one call/line.

Initially, I started with these bindings for my project Brahma, but decided it was a large enough effort to put up separately. I hope people find it useful alongside the other tools for OpenCL for .NET that are already available. I hope to have the API completed and released soon. Stay tuned.

Despite the lack of updates on this site, I have been hard at work on a new provider, Brahma.OpenCL. I am very excited at all the possibilities that OpenCL brings to the table. I will try to summarize some of the new features that OpenCL will bring to Brahma.

1. Different memory pools – OpenCL supports the idea of host memory, device memory and host-addressable memory. Brahma will allow the creation of DataParallelArrays in these memory pools and will allow host-addressable memory (and host memory) to maintain only one copy of the data.
2. Asynchronous operations – OpenCL supports the idea of asynchronous operations (data-transfers, concurrent kernel execution) and now so does Brahma. Brahma will also allow the user to introduce “fences” in any command queue for fork-join parallelism.
3. Free memory-layout – Because memory layouts vary across applications (Morton coding, bricking, overlapped bricks or other index based arbitrary data-structures), DataParallelArrays will now be independent of layout (with a layout manager YOU provide – or use a stock one). This means Data-ParallelArrays will now have arbitrary dimensionality.
4. Arbitrary data – This is perhaps very exciting. DataParallelArrays can now contain any kind of blittable struct. So, if you’re working with an equation that requires two floats and an int called a, b and factor; you can create a struct with those members and use them in your calculations!

And, to whet your appetite; here’s what Brahma.OpenCL code will look like.

// Create compiled, named query

CompiledQuery query = 

    _provider.Compile("q1", (d1, d2) => 

            from val1 in d1

            from val2 in d2

            select new Coefficients 

            { 

              a = val1.a + val2.a, 

              b = 0f,

              factor = a.factor++

            });

// Create a dataparallel array, and provide a

// memory layout implementation, and a pool to use

var d1 = new DataParallelArray<Coefficients>(

    _provider, null, length,

    new LinearMemoryLayout(length), Pool.Shared);

// Create a command that takes the array and 

// a GetValues lambda

// but - don't do anything just yet

var transferd1 += Command.Transfer(d1, 

    x => new Coefficients

             {

                 a = 0.0, 

                 b = 1.0, 

                 factor = 0

             });

// Ditto for d2 - create ...

var d2 = new DataParallelArray<Coefficients>(

    _provider, null, length,

    new LinearMemoryLayout(length), Pool.Shared);

// ... and create a transfer command

var transferd2 += Command.Transfer(d1, 

    x => new Coefficients

             {

                 a = 0.0, 

                 b = 1.0, 

                 factor = 0

             });

// Queue 0 - add the transfer command

_provider.CommandQueues[0] += transferd1;

// Queue 1 - add the transfer 

// and wait for transferd1

_provider.CommandQueues[1] += 

    new[]

        {

            transferd2, 

            Command.Wait(transferd1)

        };

// Begin running commands on queues 0 and 1

ResultSet results = _provider.Run(0, 1);

// Access results from the result-set  

foreach (Coefficient coeff in results["q1"])

    ...

Hope that got you excited . I would love to hear comments and suggestions from everyone!

For those of you who have written to me and not received a reply, please write to me again, these past few months have been terribly hectic; settling down in a new job in a new country.