Re: OpenCL

[Evan Wies <evan@...>]

You might be interested in looking at PyCUDA, which is Python bindings to CUDA with good integration
with Numpy.  It is implemented via SWIG, along with scaffolding in Python.

It might give you good ideas for how you want to integrate OpenCL with Lua.

http://mathema.tician.de/software/pycuda

-Evan

askok@dnainternet.net wrote:
> 
> Good insight.  And I did notice the PDF had come out; will read it later
> today.
> 
> Though I think all essentials were in your mail.  :)   For the
> particular itch (not necessarily needing to use Lua) we might then
> consider "OpenCL-friendly" way of defining the macros. We'll see.
> Running Lua on Cuda might still be feasible, but there are similar
> restrictions there. Not as strict, though.
> 
> -asko
> 
> 
> On Wed, 10 Dec 2008 11:42:45 +0000
>  David Given <dg@cowlark.com> wrote:
>> askok@dnainternet.net wrote:
>> [...]
>>> The best I've seen is the slides here: http://www.khronos.org/opencl/
>>
>> I've dug through the spec in the Khronos registry:
>>
>> http://www.khronos.org/registry/cl/
>>
>> The OpenCL programming language is C based, yes, but rather restricted:
>>
>> - no function pointers
>> - no dynamic memory allocation
>> - no extern or static
>> - no recursion
>> - memory can only be written in units of 32 bits or bigger (e.g., char
>> pointers are read-only) (although particular platforms may implement an
>> extension that allows this)
>> - irreducible control flow graphs aren't supported
>>
>> So porting the Lua interpreter is probably not going to be feasible.
>> What's more, as the whole environment is *source* based, not
>> machine-code based (your application compiles the OpenCL program at run
>> time), the actual GPU machine code could vary from platform to platform.
>> This means that trying to generate GPU instructions via LuaJIT isn't
>> going to work.
>>
>> That said, we *could* implement something like this:
>>
>>> run_on_cuda( matrix, function(x,y)
>>>     -- some big fat (or slim) equation in pure Lua for dealing with
>>> (x,y)
>>> end )
>>
>> What we'd have to do is to decompile the function, translate it into
>> OpenCL C, compile it and then deploy it to the device. Sounds scary, but
>> given that OpenCL doesn't do dynamic memory allocation, the Lua subset
>> would be so limited that it wouldn't be as bad as it sounds (and we'd
>> probably want to use a program in a string, anyway, because function
>> decompiling is non-portable). Add in some appropriate language
>> extensions and it might become quite usable; it would allow the user to
>> gloss over all the horrible details of communicating with the host,
>> creating the OpenCL environment, etc.
>>
>> Of course, it *would* require someone to write a LuaCL -> OpenCL
>> compiler...
>>
>> -- 
>> David Given
>> dg@cowlark.com
> 
>