[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: OpenCL
- From: askok@...
- Date: Wed, 10 Dec 2008 15:10:47 +0200
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 <email@example.com> 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
- 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
What's more, as the whole environment is *source* based,
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
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)
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,
decompiling is non-portable). Add in some appropriate
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...