New Octave package "OCL" providing OpenCL support

[Matthias W. Klein]

Dear Octave maintainers,

I have developed a new Octave package named "OCL" which uses OpenCL as
parallelization to speed up a broad familiy of Octave calculations.  It
implements a functionality similar to Matlab's 'gpuArray' core concept,
but avoids restrictions on hardware type and vendor.

The package uses Octave C++ user data types for various new numeric
OpenCL-based array datatypes, and also for general OpenCL programs.  The
package includes some 900 lines of test code, a central README
documentation file for users and developers, and detailed online help
texts for all functions reachable from the interpreter.  The current
version 0.9.0 runs under Windows (MXE builts) and Linux, and Octave
versions 3.6.0 to 4.2.2.  I tested it with several OpenCL drivers.

I developed the OCL package privately, and I hold a copyright disclaimer
signed by my employer referring to this package name.

The package is currently hosted at 'sourceforge.net/p/octave-ocl' for
your immediate reference.

I hereby kindly request that the OCL package become officially
affiliated to Octave Forge, and seek your advice in doing so.

Moreover, I am looking for co-maintainers for the package.  Interested
collaborators are welcome to contact me.

Additionally, I propose the following aspects, from my side, as first
steps for exchange and collaboration:

1.) GPL3 license/legal aspect:
To my understanding, the existence of Mesa/Clover as a free open source
OpenCL library renders ALL OpenCL libraries to be "System Libraries" as
defined by the GPL3.  Is this correct?  This is a crucial aspect I would
like at least from two of you maintainer guys to comment on.  A more
detailed reasoning can be found at the beginning of my ocl_lib.cc file,
which we might want to revise.

2.) Decision on "community package" vs. "external package":
In my impression, the OCL package is better suited to be a community
package, rather than an external package, because OCL is mainly C++ code
relying strongly on C++ Octave code (e.g., octave_base_value class,
macros).  Please let me know your maintainers' opinions.  Apart from a
technical estimation, there might also be aspects of how strongly myself
would be required to interact frequently.  I am a Mercurial intermediate
learner so far, with mainly home experience, willing to extend my
knowledge moderately.

3.) Upgrade to current Octave version:
Octave versions 4.4/5.1 (the relevant internal features seem to be quite
similar in the two versions) abolish the 'symbol_table::add_dispatch'
function.  I am using this function in all previous Octave versions to
redirect standard interpreter functions (like "max", "cumsum" etc.)
called with OCL matrix arguments to the package's OCL functions.  I
currently do not know yet what alternative mechanism can be used.  This
is a programming aspect of collaboration.  Successful extension to
include also the current Octave version, in my opinion, would deserve
the package version 1.0.0.

4.) Project structure and compile time:
While 'make dist' creates the correct installable release tarball, I
chose to have the project structure to be a flat directory and to use my
own rather simple Makefile.  This is mostly due to the fact that, for
the usual repeated incremental code developing and testing, I am using
'make' for partial rebuilts (called from a specifically chosen Octave
environment and using my make.m).  This procedure avoids frequent full
rebuilding or installing of the package, which on my computer takes more
than a minute each time.  The compilation time results from intensive
declaration and instantiation of C++ templates for the OCL data type
classes.  Any help on making compilation of the C++ templates more
efficient is appreciated.  Apart from that, this is an explanation on
why I recommend to retain the non-standard project structure, at least
for the time being.

I am delighted to contribute to Octave!

Thank you in advance for your advice, help, and cooperation!

Best regards,

Matt
(Matthias W. Klein)