cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated GSoC 2014 Ideas (markdown)

This commit is contained in:
Andreas Rumpf 2014-02-13 01:13:37 -08:00
parent 1570b9275e
commit 9e01d783c0
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
GSoC-2014-Ideas.md
View File

@ -43,6 +43,18 @@ ___
Nimrod currently supports C, C++, Objective C and JavaScript code generation. However to run efficiently on GPUs an OpenCL backend is required. The easy way to do this is to copy OpenCL's low level mode of operation with its different ``private``, ``local``, ``global`` storage and simply provide a nimrodic syntax for OpenCL. So apart from syntactic sugar users get all of Nimrod's meta programming advantages plus good integration into Nimrod's infrastructure. Nimrod currently supports C, C++, Objective C and JavaScript code generation. However to run efficiently on GPUs an OpenCL backend is required. The easy way to do this is to copy OpenCL's low level mode of operation with its different ``private``, ``local``, ``global`` storage and simply provide a nimrodic syntax for OpenCL. So apart from syntactic sugar users get all of Nimrod's meta programming advantages plus good integration into Nimrod's infrastructure.
The vision is a ``gpu`` pragma that means a proc and all of its dependencies are translated into OpenCL instead of C but can be invoked from ordinary Nimrod code that is translated to C. The ``gpu`` code generator is allowed to only translate a subset of Nimrod, in particular things like function pointers that are not supported by OpenCL do not have to be supported. The compiler should produce a clean error message for unsupported features.
**Expected Result:** The GPU code generator works on a selected set of examples/test cases.
**Tasks:**
* Add support for new pointer types in the compiler like ``global``, ``private``.
* Add support for workg groupss.
* Add support for the ``gpu`` pragma that translates to the OpenCL, version 2: https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/
**Bonus points:** Support version 1.2 of the OpenCL specification: https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/. This should be significantly harder as version 1.2 doesn't support a shared address space with the host environment.
**Difficulty:** Hard **Difficulty:** Hard
**Mentor:** Araq ([@Araq](http://github.com/Araq)) **Mentor:** Araq ([@Araq](http://github.com/Araq))