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.

I’ve finally sorted out all problems with Brahma and OpenGL, and I’m glad to announce that there will be a release of Brahma that runs on Mono (Windows + Linux, but not MacOS – I don’t have bindings for it) very soon. I’m going to be using my own method of initializing an OpenGL context on Windows and X11 using the Tao bindings for both. Stay tuned for screenshots of the samples running on Linux!

I’m really excited as I’ve never done any significant cross-platform coding, and it’s always nice to see write-once, run anywhere code!

Comments and suggestions are welcome as always.

I’ve been trying to get Brahma working with OpenGL, and although the code is complete to bring the OpenGL/GLSL provider on par to the DirectX provider (GLSL code is generated, compiles fine), I’m having problems getting results back from the GPU. I really wish OpenGL would DO something about the dreadful uncertainties across versions, vendors and drivers. I got a whiff of something called OpenCL that’s being cooked up. If delivered properly, it might be answer to a lot of woes. Anyway, I digress. There’s enough material there for a whole new post

I’m having problems getting a proper data-round trip between the CPU and GPU (I’m using FBO’s). I’m not sure why that is, but it works if I don’t perform any renders, but just crashes the moment I do. Since I’m at a loss as to what’s going on, I though I’d give a holler to any OpenGL experts out there who can help me figure out what’s going on.

The two unit tests of relevance in this case are

1. DataRoundTrip
2. IdentityTransform

Weird. Hope someone can help me figure this out soon, I’d really like to get this baby running on Linux and Mono. Thanks in advance for any help!

After a lot of stumbling blocks with SelectMany and Lets, Brahma is finally out and it supports both of them. The latest release is 0.3, and can be found over at Sourceforge. This release contains 3 samples.

1. A CPU vs GPU implementation of a the Odd-Even transposition sort. This shows comparable performance for sorting floats (simple calculations), and the GPU version is as much as 5 times faster when sorting Vectors, where the length of each vector needs to be computed.
2. Conway’s Game of Life. This sample shows how to express logic in a query. Here the “rules” for the game of life are written as a single query and simulates “life” on a 512×512 grid.
3. This example visualizes the Mandelbrot set using the escape time algorithm. An iterative version of the algorithm is implemented since it works well with queries. This is a sightly complex example and uses more than one query to compute a result. This shows how multiple queries can be strung together with no loss of performance.

I know a lot of you would like to see some sort of documentation, so I am working on a wiki which should be up soon. In the meantime, please direct all queries directly to me.

I would love your feedback, so if you have any comments or suggestions, drop me a line using the “Contact me” link.

Despite the lack of updates on the main Brahma page, development is still on, and this morning saw the checking in of more code, with the following features for 1D and 2D data-parallel arrays.

• Identity transforms (obviously!)
• Simple arithmetic operations (supported operators are +, -, * and /.
• One function call (at the moment) to Math.Sqrt is supported. It’s quite simple to add more, so if there’s a HLSL intrinsic function you absolutely need, give me a holler.
• Dependent reads – You can use a looked up value to index into a data-parallel array again.
• Indexing – The “Current” property, “CurrentX” and “CurrentY” properties in DataParallelArray<T> and DataParallelArray2D<T> allow you to use adjacent elements in you computations.

Coming up, I am working on conditionals (ternary).

I am also contemplating the use of a DataParallelArray “pool”, which can quickly be used to get new textures instead of the current method of creating them when required. I would appreciate any feedback on this method, and any suggestions for speedup or other improvements you may need.

Get the latest sources from SVN as usual, Brahma.DirectX.Tests contains the code to get you started.