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
