• 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.

So I spent the better part of my evening writing something that I hope I will be able to carry around as a code snippet small enough to use anytime, anywhere in an elegant fashion.

#region CommandLine



static class CommandLine


{


	public class Switch // Class that encapsulates switch data. Not meant for direct use.


	{


		public Switch(string name, Action<IEnumerable<string>> handler, string shortForm = null)


		{


			Name = name;


			Handler = handler;


			ShortForm = shortForm;


		}



		public string Name


		{


			get;


			private set;


		}


		public string ShortForm


		{


			get; private set;


		}


		public Action<IEnumerable<string>> Handler


		{


			get; private set;


		}



		public int InvokeHandler(string[] values)


		{


			Handler(values);


			return 1;


		}


	}



	// The regex that extracts names and comma-separated values for switches 


	// in the form (<switch>[:value,value,value])+


	private static readonly Regex _regex =


		new Regex(@"\s*(?<switch>(?<name>\w+)(:\s*(?<value>\w+(\s*,\s*\w+)*))?)",


			RegexOptions.Compiled | RegexOptions.CultureInvariant |


			RegexOptions.ExplicitCapture | RegexOptions.IgnoreCase);



	private const string NameGroup = "name"; // Names of capture groups


	private const string ValueGroup = "value";



	public static void Process(this string[] args, Action printUsage, params Switch[] switches)


	{


		// Run through all matches in the concatenated argument list and if any


		// of the switches match, get the values and invoke the handler we were


		// given. We do a Sum() here for 2 reasons; a) To actually run the handlers


		// and b) see if any were invoked at all (each returns 1 if invoked).


		// If none were invoked, we simply invoke the printUsage handler.


		if ((from Match match in _regex.Matches(string.Join(" ", args))


			 from arg in switches


			 where match.Success &&


				   ((string.Compare(match.Groups[NameGroup].Value, arg.Name, true) == 0) ||


					(string.Compare(match.Groups[NameGroup].Value, arg.ShortForm, true) == 0))


			 select arg.InvokeHandler(match.Groups[ValueGroup].Value.Split(','))).Sum() == 0)


			printUsage(); // We didn't find any switches


	}


}



#endregion

All of the magic happens inside the Process method, where the query tries to match the arguments against the ones we want to check for. The .Sum() aggregate method does two things.

1. It enumerates the elements of the IQueryable, actually calling the handlers in the process. Nothing happens till then!
2. Each of the InvokeHandler calls returns 1, so the result of the .Sum() is 0 if there were no matches (which is when we call the supplied printUsage handler).

Neat, huh? Using it is even simpler!

            args.Process(


                () => Console.WriteLine("Usage is switch0:value switch:value switch2"),


                new CommandLine.Switch("switch0",


                    val => Console.WriteLine("switch 0 with value {0}",


                        string.Join(" ", val))),



                new CommandLine.Switch("switch1",


                    val => Console.WriteLine("switch 1 with value {0}",


                        string.Join(" ", val)), "s1"),



                new CommandLine.Switch("switch2",


                    val => Console.WriteLine("switch 2 with value {0}",


                        string.Join(" ", val))));


        }

Any handlers you provide will be called for each switch or it’s shortform(if found, of course). Now get started writing those fantastic console applications.

Obligatory disclaimer and License: The code above is for you to do whatever you want to. Even if it blows you up (like Dr. Manhattan blows Rorschach up), don’t come back from the dead to haunt me. I would, however appreciate it if you kept the comment attributing that code to me.

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.

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