I have fixed the Brahma | Downloads page, and it is back up. Thanks to everyone who pointed that out, and sorry it took so long for me to get around to it!

Ok, I finally got around to cleaning up the Brahma code (just a little, mind you – there’s loads more to do!) and checking it in! Yes, that means you can try it out now! Because there are no releases, you’re going to have to check out the code with the instructions from here. The source contains a few samples I showed off at the Twin Cities Code Camp last weekend, so that’s the place to start poking around. I would love to see questions, suggestions and offers for help with samples .

I’m hoping to be able to put in more work on Brahma in a week or so, so stay tuned!

Earlier versions of Brahma used a LINQ statement exactly like a query. You could “transform” data, but weren’t allowed any control over where it went in the output. You could also just “select” one value, no more and no less. Another limitation was; when operating on two differently sized data-parallel arrays (Phew! That’s a mouthful!) you had to make a choice about the size of the output, the “kernel” would be called for all elements in the output array. It was also hard to loop, do conditionals and other kinds of logic that are almost indispensable in complex algorithms.

With OpenCL, kernel code has finally become expressive enough to truly perform general purpose computations. Brahma allows you (albeit in a limited fashion due to current language restrictions – of course, if we could write multiline lambdas and the compiler would give me expression trees of those, I wouldn’t have any of these “workarounds”. Oh, well.) to do this:

provider.CompileKernel<Buffer<int32>, Buffer<int32>>((d1, d2) =>


    from x in Loop.For(() => 0, i => i < _width, i => i + 1)


    from y in Loop.For(() => 0, i => i < _height, i => i + 1)


    let idx = y * _width + x


    select new[]


    {


        result1[idx] <= (d1[idx] + d2[idx]),


        result2[idx] <= (d1[idx] - d2[idx])


    });

Note that DataParallelArray<T> is now called Buffer<T> – isn’t that a lot easier? The kernel above is two nested loops that calculate something off two 2D images and write the results to 2 output buffers called result1 and result2. (I know the example doesn’t make sense, it’s just there to show usage!)

The observant among you probably noticed a few things

• I AM selecting one output item for each inner loop iteration (= _width * _height items) – Well, yes. But I’m writing two results each time (I can write none if I don’t want to).
• Why am I comparing result[idx] and (d1[idx]….)? Nope. Brahma overloads the <= operator and in this case you read it as “is assigned”. So in Brahma parlance, you’re saying: result[idx] “is assigned” d1[idx]….
• result1 and result2 are NOT lambda parameters. While Brahma will allow you to use only “side-effects”, you can also use other overloads to provide parameters that you assign to. This comes in handy when you want to use different output buffers but compile the query only once.

And in that sense, you are also free to pass non-buffer arguments to the kernel (and write to them from one – depending on your compute device you may have memory restrictions, though). For example, a structure containing control values can now be “passed” in per run!

Here’s one more (idiotic) sample that uses the current thread id instead of running nested loops per kernel launch. Ok, so I’m still thinking about the DeviceMethods name.

provider.CompileKernel<Buffer<int32>, Buffer<int32>>((d1, d2) =>


    from x in DeviceMethods.GlobalID(0) // ID (and coordinates) of the thread


    from y in DeviceMethods.GlobalID(1)


    let idx = y * _width + x


    select new[]


    {


        result1[idx] <= (d1[idx] + d2[idx]),


        result2[idx] <= (d1[idx] - d2[idx])


    });

I think the new kernel syntax/usage is neat, functional and compact. What do you think? I’m still working on several bits of this design … so this is when you can be heard! Please tell me what you think!

I’m at the nVidia GPU conference and I just learned of (and met) a company called TidePowerd, who seem to have taken the IL decompilation idea (that Brahma 1.0 was based on) into a commercial product. This, to me is good because

1. It looks like someone thought many-core/GPGPU developer tools for .NET was an idea worthy of commercialization (a drum I’ve been banging for many years now)
2. It’s nice to see the seed of the idea that IL can be effectively transformed to SIMD/SIMT type code be realized in a fuller fashion.

Personally, I’d be REALLY interested in seeing what TidePowerd does and how the industry responds to their offerings.

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.

What does Windows 7 have to do with music? Nothing, really. But I’ve noticed that no one has been enterprising enough to put the Window 7 taskbar features to REALLY good use and make an mp3 player that we can use while we work (WMP team, are you listening?). I mean, who doesn’t listen to music while working? Everyone who raised their hands can leave the room now. Just kidding.

Onto the good stuff. Lyre sits in your taskbar, updates the application icon with the album art (if present), shows play progress on the taskbar button and provides all the basic play controls as thumb-buttons on the taskbar. There are no visualizations yet, but they should be easy enough to do if there’s enough demand for it. Here are some screenshots:

Here’s the player with controls, progress and tag-reading.

You can control the player by using it’s jump list.

True, this project only took me a week to complete (to this level), but there were a lot of unknowns and problems with the managed Windows7 integration wrapper. Well, I guess I should write a blog post on those later

Download it here, give it a whirl and let me know what you think.

Lyre-setup.zip