Re: OpenCL

[David Given <dg@...>]

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