lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


On Wed, 10 Dec 2008 11:42:45 +0000
 David Given <> wrote: wrote:
The best I've seen is the slides here:

I've dug through the spec in the Khronos registry:

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