nythrix's picture

[Compute] Hi-level OpenCL

Project:The Open Toolkit library
Version:1.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:nythrix
Status:closed
Description

This thread is dedicated to the layer of high level OpenCL classes. The layer is to provide an easy to use alternative to the flat bindings which are quite hard to use in managed code. Ideas, recommendations, moral support and/or night cries backed by torches and hay-forks are welcome.


Comments

Comment viewing options

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

#11

Hi, I've been working on my own high level C# OpenCL wrapper for one of my projects, but I'm thinking that my time might be better spent helping out with the OpenTK project instead. I'm still just familiarizing myself with OpenTK, but I do have a fair ammount of experience making C# inter-operate with unmanaged code.

A couple of suggestions regarding the Get*Info methods:
Instead of creating a method that takes a GetStructInfo delegate and then tries to figure out what the correct CL call is, it might be easier to add an abstract GetRawInfo(...) method to your base ComputeObject class. When child classes override it, they can deal with converting paramName to the correct Enum, like so:

	abstract public class ComputeObject
	{
		//Asks an object to get raw info using the appropriate CL.Get*Info method.
		//Child classes deal with converting paramName to an enum type.
		abstract protected void GetRawInfo(int paramName, IntPtr valueSize, IntPtr valuePtr, out IntPtr returnedSize);
 
		//Reads raw info and returns it as a uint
		protected uint GetUIntInfo(int paramName)
		{
			uint result = 0;
			IntPtr returnedSize;
			unsafe{
				GetRawInfo(paramName, (IntPtr)sizeof(uint), (IntPtr)(&result), out returnedSize);
			}
			return result;
		}
 
		//Reads raw info and returns it as a string
		protected string GetStringInfo(int paramName)
		{
			string result = null;
			IntPtr size;
			//first get the size of the string
			GetRawInfo(paramName, IntPtr.Zero, IntPtr.Zero, out size);
 
			IntPtr returnedSize;
			//allocate a large enough buffer
			IntPtr strBuf = Marshal.AllocHGlobal(size);
			try{
				GetRawInfo(paramName, size, strBuf, out returnedSize); //query the string
				result = Marshal.PtrToStringAnsi(strBuf); //convert to a .NET string
			}
			finally{
				Marshal.FreeHGlobal(strBuf); //cleanup
			}
			return result;
		}
		//... more methods to read floats, size_t, size_t[],etc... info ...
	}
 
	public class Device : ComputeObject
	{
		internal IntPtr handle = IntPtr.Zero;
 
		public string Name{
			get{ return GetStringInfo((int)DeviceInfo.DeviceName); }
		}
		public uint MaxComputeUnits{
			get{ return GetUIntInfo((int)DeviceInfo.DeviceMaxComputeUnits); }
		}
		//...rest of properties here...
 
		protected override void GetRawInfo(int paramName, IntPtr valueSize, IntPtr valuePtr, out IntPtr returnedSize)
		{
			int err = CL.GetDeviceInfo(this.handle, (DeviceInfo)paramName, valueSize, valuePtr, out returnedSize);
			//...deal with errors here...
		}
	}

This puts all of the nasty unsafe code that converts raw info to .NET types in the base ComputeObject class. I'm not sure if any of this will jive with your existing codebase, but I thought I'd put it out there anyway.

Anyway, I'm looking forward to writing OpenCL apps, so let me know if there's anything I can do to help OpenTK.

nythrix's picture

#12

Thanks guys. Once more the hardest part in finding the right answer is asking the right question :) It's now working the way I intended it to.

the Fiddler's picture

#13

Nice, I'm really looking forward to this.

@fractron9000: it would be really helpful if you could implement one or two tests (or tutorials if you will) to exercise the low-level OpenCL bindings. These bindings are pretty hairy right now, but we need actual test cases before we can improve them.

In the mid- to long-term, I expect nythrix's high-level bindings to become the preferred way to access OpenCL, however a good low-level API will still be useful - and for that, we need help from someone familiar both with unmanaged interop and with OpenCL. If you have any suggestions or even code to share, please make a post!

nythrix's picture

#14

Version:0.9.x-dev» 1.x-dev

I'm slowly approaching alpha, Fiddler. It's ready for testing as long as you don't mess with images (#1368: [OpenCL] Several delegates buggy). So, do I stick the project somewhere? Or is it going straight into the repository?

the Fiddler's picture

#15

Great!

There are a few different options to publish the code. If you are not using version control right now, you can create a new project on opentk.com and upload the code there. I can then add the code to the git repository of opentk and give you write access so you can work directly on that. (Why not the svn repository? Because svn branching/merging is exceedingly painful and this will come back and bite us down the road. I'm planning to move opentk to git anyway).

If your code is already under version control, the process will be a little more complicated as it would be nice to keep the history intact. This is generally possible, but the exact details depending on your current VCS.

Finally, an alternative solution would be to register a new project on sourceforge/launchpad/github/whatever and publish the code there. This is also fine by me.

the Fiddler's picture

#16

I am closing this issue. Bugs and feature requests on high-level OpenCL should now be reported against the Cloo project.

the Fiddler's picture

#17

Status:open» closed