[racket] OpenCL module macro errors

From: Dane Larsen (dane at larsendt.com)
Date: Sat Aug 24 22:02:54 EDT 2013

Hmm. I think I almost have it, but there's one error I can't seem to 
track down.

Switching from _arg_type to arg_id seems to have almost worked, but now 
I'm stuck. When I try to run my context sharing test program 
(https://github.com/larsendt/cl-gl-context-sharing/) I get the following:

vector-length: contract violation
   expected: vector?
   given: #<ctype>
   context...:
 
/home/dane/chematox/local/racket-5.90.0.6/collects/ffi/unsafe.rkt:27:27: 
vector->cblock
    /home/dane/git/opencl/opencl/c/syntax.rkt:160:13
    /home/dane/git/opencl/opencl/c/syntax.rkt:216:11: 
clGetGLContextInfoKHR:generic
    /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt:30:6
    /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt:18:2
 
/home/dane/chematox/local/racket-5.90.0.6/collects/racket/private/class-internal.rkt:4070:0: 
continue-make-object
 
/home/dane/chematox/local/racket-5.90.0.6/collects/racket/private/class-internal.rkt:4051:0: 
do-make-object
    /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt: [running body]

It looks like the error is happening in the definition of _vector, which 
calls vector->cblock. I assumed that would be in the conversion of the 
input 'properties' vector 
(https://github.com/larsendt/cl-gl-context-sharing/blob/master/sinemesh-gl.rkt#L46), 
but that's definitely a vector, not a ctype. There aren't any other 
inputs being passed to _vector, so I honestly have no idea what's 
causing it.

I put up my fork of the opencl module with the changes at 
https://github.com/larsendt/opencl/. The definition of 
clGetGLContextInfoKHR lives at 
https://github.com/larsendt/opencl/blob/master/opencl/c/9-7.rkt#L19.

Thanks for the help so far. I'm still getting my bearings in 
macro-world, and it's definitely showing today.

Dane


On 08/23/2013 09:29 AM, Jay McCarthy wrote:
> Hi Dane,
>
> Thanks for working on this.
>
> If you look at line 106 of the definition of define-opencl-info, it
> uses the _arg_type as the name of the selector's arguments. I think
> you could safely replace that with arg_id, if not, then you would want
> to create new ids with generate-temporaries, but try arg_id first.
>
> Since this looks like a simple change, try it on your end and we can
> just include it in the pull request/patch you send me.
>
> Jay
>
>
> On Thu, Aug 22, 2013 at 7:54 PM, Dane Larsen <dane at larsendt.com> wrote:
>> Hi all,
>>
>> I'm a little new to Racket (and Lispy languages in general). I'm working on
>> extending the OpenCL module to add support for OpenGL context sharing.
>>
>> My questions are somewhat specific to the OpenCL module, but hopefully I can
>> provide enough context to minimize that.
>>
>> Right now I'm working on clGetGLContextInfoKHR in, and it's been a bit more
>> challenging than I anticipated. It's a CL extension function, so get-ffi-obj
>> fails to find it. This hasn't been a huge problem. I ended up creating an
>> alternate version of define-opencl (
>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/lib.rkt#L17)
>> which I've called define-opencl-extension. Rather than calling get-ffi-obj,
>> it calls clGetExtensionFunctionAddress. That part works great.
>>
>> The big problem that I'm having right now is with define-opencl-info (
>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/syntax.rkt#L18),
>> which essentially provides a convenient interface for the clGet*Info
>> functions (which all have similar arguments). clGetGLContextInfoKHR follows
>> that pattern with one exception. It's primary input argument takes a vector
>> of values, rather than a single value.
>>
>> A call to define-opencl-info looks like this:
>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/5-3.rkt#L76
>>
>> I thought I had the correct syntax by essentially replacing line 79 with the
>> following:
>>
>> (args [properties : (_vector i _cl_context_properties)
>> _cl_context_properties_vector/c])
>>
>> (I've also replaced the other types and argument names and whatnot, but that
>> all seems to work).
>> Anyway, with the (_vector ...) call, I get the following error:
>>
>> ; c/9-7.rkt:26:22: define: not an identifier, identifier with default, or
>> ;   keyword for procedure argument
>> ;   at: (_vector i _cl_context_properties)
>> ;   in: (define (clGetGLContextInfoKHR:generic (_vector i
>> ;     _cl_context_properties) _cl_gl_context_info) (case (hash-ref
>> ;     id-selector-map _cl_gl_context_info #f) ((_cl_device_id*) (local
>> ((define
>> ;     len (clGetGLContextInfoKHR:length (_vector i
>> _cl_context_properties)...
>> ; [,bt for context]
>>
>> I'm not sure what that error is referring to, or how to fix it.
>> Here's the backtrack, but it's not terribly helpful (that I can see,
>> anyway):
>>
>> ; c/9-7.rkt:26:22: define: not an identifier, identifier with default, or
>> keyword for procedure argument
>> ;   at: (_vector i _cl_context_properties)
>> ;   in: (define (clGetGLContextInfoKHR:generic (_vector i
>> _cl_context_properties) _cl_gl_context_info) (case (hash-ref id-selector-map
>> _cl_gl_context_info #f) ((_cl_device_id*) (local ((define len
>> (clGetGLContextInfoKHR:length (_vector i _cl_context_properties)...
>> ;   context...:
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/norm-define.rkt:46:33:
>> simple-proto
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/norm-define.rkt:134:33:
>> general-proto
>> ;    try-next
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/kw.rkt:804:2
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/modbeg.rkt:46:4
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>> ;    standard-module-name-resolver
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>> ;    standard-module-name-resolver
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>> ;    standard-module-name-resolver
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>> ;
>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/misc.rkt:87:7
>>
>> In addition, when I replace the (_vector ...) stuff with a plain old
>> _cl_context_properties, everything works fine (but the contract fails when I
>> actually try to call clGetGLContextInfoKHR, as expected).
>>
>> What am I doing wrong? It looks like (_vector i _cl_context_properties) is
>> just as much of a ctype as _cl_context_properties, so why does it fail when
>> I make it a vector?
>>
>> Thanks a ton,
>> Dane Larsen
>>
>> ____________________
>>    Racket Users list:
>>    http://lists.racket-lang.org/users
>>
>
>
>


Posted on the users mailing list.