www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - OpenCL bindings

reply "Lemonfiend" <lemon fie.nd> writes:
Hi,

I'm interested in updating the existing OpenCL bindings 
(https://github.com/Trass3r/cl4d) so they work with Derelict3, 
but have never undertaken such a task.
I'm not sure where/how to begin.

Does anyone have any advice? :)
Mar 19 2013
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 19 March 2013 at 14:30:19 UTC, Lemonfiend wrote:
 Hi,

 I'm interested in updating the existing OpenCL bindings 
 (https://github.com/Trass3r/cl4d) so they work with Derelict3, 
 but have never undertaken such a task.
 I'm not sure where/how to begin.

 Does anyone have any advice? :)
Trass3r's binding is static, with a wrapper on top of it. Plus, the binding (in the 'c' package) uses mixins to some end (just gave it a cursory look, so not clear on the details). I don't think there's anything to "update" here. It's a different approach entirely than what I take with Derelict. My advice is just to start from scratch. Look at the smaller Derelict packages (DerelictAL, DerelictFT, DerelictGLFW3) for the basic layout. I'm not familiar with the OpenCL API. Never used it or looked at it, so I don't know if you'll need something as more complex like the DerelictGL3 package. But the basic idea is to put all type declarations in one module named types.d, all function pointer alias and declarations in functions.d, and then load everything up via a subclass of SharedLibLoader in a module named appropriately for the binding (in this case, cl.d would be a good choice, with derelict.opencl as the package name). This is actually something I've wanted to get around to for a long time. I'm busier than ever these days so I can't take it on right now for sure. If you do decide to get busy on it, drop by the Derelict forums[1] if you need any help. You could email me, too, but I imagine that any advice I give you could be useful for others wanting to work on a Derelictified binding.
Mar 19 2013
next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 19 March 2013 at 14:55:10 UTC, Mike Parker wrote:

 This is actually something I've wanted to get around to for a 
 long time. I'm busier than ever these days so I can't take it 
 on right now for sure. If you do decide to get busy on it, drop 
 by the Derelict forums[1] if you need any help. You could email 
 me, too, but I imagine that any advice I give you could be 
 useful for others wanting to work on a Derelictified binding.
[1] http://dblog.aldacron.net/forum/index.php
Mar 19 2013
prev sibling parent reply "Lemonfiend" <lemon fie.nd> writes:
On Tuesday, 19 March 2013 at 14:55:10 UTC, Mike Parker wrote:
 On Tuesday, 19 March 2013 at 14:30:19 UTC, Lemonfiend wrote:
 Hi,

 I'm interested in updating the existing OpenCL bindings 
 (https://github.com/Trass3r/cl4d) so they work with Derelict3, 
 but have never undertaken such a task.
 I'm not sure where/how to begin.

 Does anyone have any advice? :)
Trass3r's binding is static, with a wrapper on top of it. Plus, the binding (in the 'c' package) uses mixins to some end (just gave it a cursory look, so not clear on the details). I don't think there's anything to "update" here. It's a different approach entirely than what I take with Derelict.
That's a shame.
 My advice is just to start from scratch. Look at the smaller 
 Derelict packages (DerelictAL, DerelictFT, DerelictGLFW3) for 
 the basic layout. I'm not familiar with the OpenCL API. Never 
 used it or looked at it, so I don't know if you'll need 
 something as more complex like the DerelictGL3 package. But the 
 basic idea is to put all type declarations in one module named 
 types.d, all function pointer alias and declarations in 
 functions.d, and then load everything up via a subclass of 
 SharedLibLoader in a module named appropriately for the binding 
 (in this case, cl.d would be a good choice, with 
 derelict.opencl as the package name).
I see. That's a larger project than I'd hoped. Considering I've never created a binding before, is there some kind of tutorial/recommended reading available?
 This is actually something I've wanted to get around to for a 
 long time. I'm busier than ever these days so I can't take it 
 on right now for sure. If you do decide to get busy on it, drop 
 by the Derelict forums[1] if you need any help. You could email 
 me, too, but I imagine that any advice I give you could be 
 useful for others wanting to work on a Derelictified binding.
Mar 19 2013
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 19 March 2013 at 15:03:11 UTC, Lemonfiend wrote:

 I see. That's a larger project than I'd hoped. Considering I've 
 never created a binding before, is there some kind of 
 tutorial/recommended reading available?
There's a page at dlang.org[1], and I have a series of 5 blog posts on the topic over at gamedev.net, starting with part 1[2]. [1] http://dlang.org/interfaceToC.html [2] http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Mar 20 2013
parent reply "Andrea Fontana" <nospam example.com> writes:
On Wednesday, 20 March 2013 at 08:13:45 UTC, Mike Parker wrote:
 On Tuesday, 19 March 2013 at 15:03:11 UTC, Lemonfiend wrote:

 I see. That's a larger project than I'd hoped. Considering 
 I've never created a binding before, is there some kind of 
 tutorial/recommended reading available?
There's a page at dlang.org[1], and I have a series of 5 blog posts on the topic over at gamedev.net, starting with part 1[2]. [1] http://dlang.org/interfaceToC.html [2] http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
You're missing dstep. Using dstep I converted some c-libraries in short time. It's quite easy to use and usually just some minor modification are needed to adjust auto-generated d interface.
Mar 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 12:09, Andrea Fontana wrote:

 You're missing dstep. Using dstep I converted some c-libraries in short
 time. It's quite easy to use and usually just some minor modification
 are needed to  adjust auto-generated d interface.
I was just about to suggest to use dstep. I'm glad to see that you found it useful. -- /Jacob Carlborg
Mar 20 2013
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Wednesday, 20 March 2013 at 12:43:13 UTC, Jacob Carlborg wrote:
 On 2013-03-20 12:09, Andrea Fontana wrote:

 You're missing dstep. Using dstep I converted some c-libraries 
 in short
 time. It's quite easy to use and usually just some minor 
 modification
 are needed to  adjust auto-generated d interface.
I was just about to suggest to use dstep. I'm glad to see that you found it useful.
Can dstep output function declarations as aliased function pointers in the format I use in Derelict?
Mar 20 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-20 14:25, Mike Parker wrote:

 Can dstep output function declarations as aliased function pointers in
 the format I use in Derelict?
I guess I could make an option for that. -- /Jacob Carlborg
Mar 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 14:25, Mike Parker wrote:

 Can dstep output function declarations as aliased function pointers in
 the format I use in Derelict?
BTW, why does it uses aliases and not declare a function pointer directly? -- /Jacob Carlborg
Mar 20 2013
parent reply "Mike Parker" <aldacron gmail.com> writes:
On Wednesday, 20 March 2013 at 19:54:42 UTC, Jacob Carlborg wrote:
 On 2013-03-20 14:25, Mike Parker wrote:

 Can dstep output function declarations as aliased function 
 pointers in
 the format I use in Derelict?
BTW, why does it uses aliases and not declare a function pointer directly?
Because some time ago DMD started shipping with '--export-dynamic' in the config file on Linux to (AFAIK) facilitate generation of exception stack traces. I was using straight function pointers at the time and, as a result, no one could use Derelict on Linux because of symbol clashes (e.g. the function pointer for glClear would clash with the glClear symbol in the shared lib). Switching to aliased function pointers was the work around. I will never "get" Linux.
Mar 20 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-21 04:37, Mike Parker wrote:

 Because some time ago DMD started shipping with
 '--export-dynamic' in the config file on Linux to (AFAIK)
 facilitate generation of exception stack traces. I was using
 straight function pointers at the time and, as a result, no one
 could use Derelict on Linux because of symbol clashes (e.g. the
 function pointer for glClear would clash with the glClear symbol
 in the shared lib). Switching to aliased function pointers was
 the work around. I will never "get" Linux.
Ok, I see. -- /Jacob Carlborg
Mar 21 2013
prev sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Wednesday, 20 March 2013 at 12:43:13 UTC, Jacob Carlborg wrote:
 On 2013-03-20 12:09, Andrea Fontana wrote:

 You're missing dstep. Using dstep I converted some c-libraries 
 in short
 time. It's quite easy to use and usually just some minor 
 modification
 are needed to  adjust auto-generated d interface.
I was just about to suggest to use dstep. I'm glad to see that you found it useful.
*Very* useful. I hope it will be updated with some small changes (like anonymous struct alias replacement and d keyword replacement) :)
Mar 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 14:59, Andrea Fontana wrote:

 *Very* useful. I hope it will be updated with some small changes (like
 anonymous struct alias replacement and d keyword replacement) :)
It should already to D keyword replacement, if not, please report an issue with a test case: https://github.com/jacob-carlborg/dstep/issues/new What is "anonymous struct alias replacement"? You can also create issues for enhancement requests. -- /Jacob Carlborg
Mar 20 2013
parent reply "Andrea Fontana" <nospam example.com> writes:
On Wednesday, 20 March 2013 at 19:10:28 UTC, Jacob Carlborg wrote:
 On 2013-03-20 14:59, Andrea Fontana wrote:

 *Very* useful. I hope it will be updated with some small 
 changes (like
 anonymous struct alias replacement and d keyword replacement) 
 :)
It should already to D keyword replacement, if not, please report an issue with a test case:
Maybe I have a old (binary) version for linux. For example params named "out" are not replaced with something else (f.e. _out)
 https://github.com/jacob-carlborg/dstep/issues/new

 What is "anonymous struct alias replacement"? You can also 
 create issues for enhancement requests.
I mean that typedef struct { ... } hello; is translate as an anonymous struct and then "aliased". I think it can be translated directly as a named struct.
Mar 20 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-20 22:02, Andrea Fontana wrote:

 Maybe I have a old (binary) version for linux. For example params named
 "out" are not replaced with something else (f.e. _out)
I checked the history and see that I added a fixed for this for function parameters just after the release. I'm pretty sure that in all other place it will handle it correctly.
 I mean that typedef struct { ... } hello; is translate as an anonymous
 struct and then "aliased". I think it can be translated directly as a
 named struct.
I see, I'm not so how easy this would be. But I can have a look. Please add an issue so it's not forgotten. -- /Jacob Carlborg
Mar 20 2013