
OpenCL
Posted Sunday, 15 February, 2009 - 10:33 by nythrix| Project: | The Open Toolkit library |
| Version: | 0.9.9-0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Here's a very rough concept of OpenCL objects and their functionality. Device class and object names taken from SVN. The rest from cl.h unchanged.
I would like some feedback on the matter, so comments are almost mandatory.
| Attachment | Size |
|---|---|
| OpenTK.Compute.zip | 5.56 KB |


Comments
#1
I would like some feedback on the matter, so comments are almost mandatory.
[Grins]
Ok, here goes! OpenCL has a nice, clean API and I think it makes sense to follow the OO route:
The user will then consume this class as:
The alternative is to follow the procedural route, where you directly expose the "UnsafeNativeMethods" class to the user (just like OpenTK.Graphics and OpenTK.Audio). This may be a little simpler to implement, but I think it's ultimately more complicated and less usable for the user. That's been my experience at least from using OpenTK.Graphics, where some rudimentary OO wrappers can cut development time a lot.
#2
I didn't even consider a 1:1 procedural layer actually. I fail to see why someone would use it deliberately. However, IF there's demand we might expose it with a "At Your Own Risk" sticker.
Some more questions about the OO layer:
- throwing exceptions or returning error codes?
- how much renaming?
CommandQueue.SetCommandQueueProperty()or a nicerCommandQueue.SetProperty()?- splitting the DllIImports into their corresponding object classes or having them in one place?
#3
I think an OO approach would be best.
#4
[Exceptions vs error codes]
Exceptions, definitely.
If there are places were failure is an expected outcome, it would make sense to add a second TryFoo() function, which returns true / false (pretty much like Dictionary.TryGetValue() in System.Collections.Generic).
[How much renaming?]
As much as possible:
CommandQueue.SetProperty()or evenCommandQueue.Property { get; set; }, if a property makes sense.CommandQueue.SetCommandQueueProperty()is ugly.[DllImports]
Better declare them directly in the classes they are used. The coding guidelines actually suggest placing DllImports in internal static classes named "UnsafeNativeMethods".
I'd also argue against exposing raw DllImports. Two reasons:
#5
Sorry for being off for so long. I was hoping for a school project involving OpenCL and C# but I didn't get approval so other things took over. However, I converted one of the examples of the OpenCL specification so that it uses the fictional Compute wrapper:
What do you think?
#6
Looks just about perfect.
The only improvement I can think of is to use plain ints instead of arrays for the globalWorkSize and localWorkSize:
What strikes me most, is that I've written a small OO OpenGL wrapper that looks like a 1-1 translation of this program: context.Create(Vertex/Element)Buffer, context.CreateProgram, program.Link and program.SetUniform. Nice to see the design validated.
Has anyone released any OpenCL implementation yet or even announced a release date? I can't seem to find anything.
#7
[EnqueNDRangeKernel]
Mmm no, they're supposed to be there. The example uses one dimensional buffers so it's not obvious but consider the following call:
AFAIK local workgroup is a kind of thread grouping that enables some extra sharing of data and state. Naive example: If you render a checkerboard you can group the threads that are going to render a tile.
Note that the concept presented here isn't expected to exactly match the OpenCL API. As suggested it will omit a lot of things that are not necessary in the managed OO world (error codes, buffer sizes, "this" arguments) or even have functions replaced by properties. Functionality should be fully preserved though.
I'm not aware of any dates. As far as roadmaps go there's OpenCL 1.1 (maintenance?) planned for Q3/Q4. I hope we might have some drivers by then...
#8
[EnqueNDRangeKernel]
Mmm no, they're supposed to be there. The example uses one dimensional buffers so it's not obvious but consider the following call:
[...]
AFAIK local workgroup is a kind of thread grouping that enables some extra sharing of data and state. Naive example: If you render a checkerboard you can group the threads that are going to render a tile.
Makes sense. Granted, I didn't read the specs just the function declaration in cl.h and the relevant parameters didn't seem to imply arrays (i.e. "global_work_offset", "global_work_size").
OpenTK provides both ref and array overloads in GL and AL, simply to avoid 1-item arrays. This was actually requested by Tao users for Tao 2.1, as they disliked allocating arrays like this.
Note that the concept presented here isn't expected to exactly match the OpenCL API. As suggested it will omit a lot of things that are not necessary in the managed OO world (error codes, buffer sizes, "this" arguments) or even have functions replaced by properties. Functionality should be fully preserved though.
Fully agreed. The sample code looks clean and very usable.
Edit:
As we reported last December, AMD plans to add OpenCL support to the Stream SDK by June. [source]
#9
As we reported last December, AMD plans to add OpenCL support to the Stream SDK by June.
Come on people, less sleep more work! :)
Back to the matter, here follows the device class. It is a typical OpenCL object and nicely demonstrates the lower level constructs of the wrapper. That, and most of my current problems with it. Anyone up for discussion?
Edit: removed some unrelated lines
#10
In any interesting twist, it seems that some Khronos members wrote a C++ binding to OpenCL. It mirrors the discussion here relatively closely.
#11
I have implemented about 80% of the OpenCL flat API. If anyone has access to pre-release OpenCL drivers, please make a post so we can test the new API.
#12
The OpenCL flat API is now 100% implemented (
OpenTK.Compute.CL). It does not contain any helper functions, just raw, CLS-compliant bindings for OpenCL.#13
Pretty good news. Too bad I only have an Intel integrated card at the moment. :(
I wish notebook GPUs were replaceable...
#14
Closing issues fixed in 0.9.9-0.