New Octave package "OCL" providing OpenCL support

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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)

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Colin Macdonald-2
On 2019-04-27 4:22 a.m., Matthias W. Klein wrote:
> 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.

Thanks, this sounds intriguing.  I'm trying it on my recent Intel
hardware.  Wasn't really clear to me how to get started from the README
(your docs look extensive but maybe could offer a little more newbie
handholding...)

Anyway, Here's what I've tried so far:

 >> ocl_double (rand (10, 10))
error: ocl_double: error while dynamically loading OpenCL library
   check library path and file name ('lib_path_filename') to point to
correct OpenCL library file

 >> ocl_lib ("lib_path_filename", '/usr/lib64', 'libOpenCL.so.1')

# (this is based on `locate -i libopencl`)

 >>  ocl_lib ("assure")
error: ocl_lib: error while dynamically loading OpenCL library
   check library path and file name ('lib_path_filename') to point to
correct OpenCL library file

Any hints?  I'm on Fedora and have installed relevant-looking stuff from
"dnf list opencl*".  "clinfo" returns lots of stuff...

thanks,
Colin

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
Hi Colin,

thanks for your hints. In short, this triggered package version 0.9.1.

Correctly installing the OpenCL drivers can, to my experience, be a
hassle sometimes. This is one of the reasons why I chose dynamic library
loading, with the possibility for user interaction. Giving details on
OpenCL driver installation, on the other side, is out of my scope;
abundant info can be found in the web.

However, since you are writing that 'clinfo' (thanks to mention!) gives
correct information, this may not be your issue.

Unfortunately, OCL 0.9.0 was very short in details about error reporting
during library loading. I changed this in today's version 0.9.1.

The new version, using octave's library loader, has thus also become, in
general, operating-system independent.

I recommend trying the new version to you. If an error persists, let me
know the error message details.

Best,
Matt

On 27.04.2019 15:40, Colin Macdonald wrote:

> On 2019-04-27 4:22 a.m., Matthias W. Klein wrote:
>> 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.
>
> Thanks, this sounds intriguing.  I'm trying it on my recent Intel
> hardware.  Wasn't really clear to me how to get started from the README
> (your docs look extensive but maybe could offer a little more newbie
> handholding...)
>
> Anyway, Here's what I've tried so far:
>
>>> ocl_double (rand (10, 10))
> error: ocl_double: error while dynamically loading OpenCL library
>   check library path and file name ('lib_path_filename') to point to
> correct OpenCL library file
>
>>> ocl_lib ("lib_path_filename", '/usr/lib64', 'libOpenCL.so.1')
>
> # (this is based on `locate -i libopencl`)
>
>>>  ocl_lib ("assure")
> error: ocl_lib: error while dynamically loading OpenCL library
>   check library path and file name ('lib_path_filename') to point to
> correct OpenCL library file
>
> Any hints?  I'm on Fedora and have installed relevant-looking stuff from
> "dnf list opencl*".  "clinfo" returns lots of stuff...
>
> thanks,
> Colin
>

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Colin Macdonald-2
On 2019-05-04 4:36 a.m., Matthias W. Klein wrote:
> thanks for your hints. In short, this triggered package version 0.9.1.

That's much better and gave me a hint what was wrong: a missing slash,
filed issue for you https://sourceforge.net/p/octave-ocl/tickets/3/

- - - - -

Now I get a segfault, but at least I've got somewhere to start:

octave:3> ocl_double (rand (10, 10))
error: ocl_double: libOpenCL.so: failed to load: libOpenCL.so: cannot
open shared object file: No such file or directory
error: ocl_double: octave's dynamic library loader reported an error
while dynamically loading the OpenCL library
   consider manual inspection with 'ocl_lib' function.

octave:4> ocl_lib ("lib_path_filename", '/usr/lib64/', 'libOpenCL.so.1')

octave:5> ocl_double (rand (10, 10))
X server found. dri2 connection failed!
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)

Oh well, progress at least ;-)  Hints what to try next?

Colin

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
I added a "Troubleshooting" section in OCL's README file, including a
list of steps / commands to test, whenever OpenCL issues or segfaults
appear.

See the tip version of README:
https://sourceforge.net/p/octave-ocl/code/ci/default/tree/README

This description reflects some experience made, but can still be
considered (advanced) work in progress.

Can you try and comment?

Matt

On 03.05.2019 23:20, Colin Macdonald wrote:

> On 2019-05-04 4:36 a.m., Matthias W. Klein wrote:
>> thanks for your hints. In short, this triggered package version 0.9.1.
>
> That's much better and gave me a hint what was wrong: a missing slash,
> filed issue for you https://sourceforge.net/p/octave-ocl/tickets/3/
>
> - - - - -
>
> Now I get a segfault, but at least I've got somewhere to start:
>
> octave:3> ocl_double (rand (10, 10))
> error: ocl_double: libOpenCL.so: failed to load: libOpenCL.so: cannot
> open shared object file: No such file or directory
> error: ocl_double: octave's dynamic library loader reported an error
> while dynamically loading the OpenCL library
>   consider manual inspection with 'ocl_lib' function.
>
> octave:4> ocl_lib ("lib_path_filename", '/usr/lib64/', 'libOpenCL.so.1')
>
> octave:5> ocl_double (rand (10, 10))
> X server found. dri2 connection failed!
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> save to 'octave-workspace' complete
> Segmentation fault (core dumped)
>
> Oh well, progress at least ;-)  Hints what to try next?
>
> Colin

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Colin Macdonald-2
On 2019-05-24 10:02 a.m., Matthias W. Klein wrote:

> I added a "Troubleshooting" section in OCL's README file, including a
> list of steps / commands to test, whenever OpenCL issues or segfaults
> appear.
>
> See the tip version of README:
> https://sourceforge.net/p/octave-ocl/code/ci/default/tree/README
>
> This description reflects some experience made, but can still be
> considered (advanced) work in progress.
>
> Can you try and comment?

I would.  But its not clear to me how to use this from source.

A while ago I filed https://sourceforge.net/p/octave-ocl/tickets/4/

I assume I put all the .c  and .h files in src/ and the .m files in inst/ ?

Also, the number of developers on this list running 4.2 is probably
shrinking.  I can do it with mtmiller's docker images but currently not
working on my system...

Colin

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
 >> I added a "Troubleshooting" section in OCL's README file...
 >>
 >> Can you try and comment?
 >
 > I would.  But its not clear to me how to use this from source.

There are two answers to that:

1.) All the steps from my troubleshooting list are commands on the
octave command line, so you don't need to bother with sources.

Since you obviously use an octave version which allows you to install
the package release tarball, the distinguishing steps are ready at your
hand - which is exactly what I intend for all users.

2.) You (as a developer) want to track down (or debug) actual causes of
segfaults etc., relying on sources.

You can work with sources and build using my Makefile. See my post to
your Ticket https://sourceforge.net/p/octave-ocl/tickets/4/ . Sorry for
the delay - I focussed on critical technical issues recently and just
didn't find the time to answer.

Matt

On 25.05.2019 01:36, Colin Macdonald wrote:

> On 2019-05-24 10:02 a.m., Matthias W. Klein wrote:
>> I added a "Troubleshooting" section in OCL's README file, including a
>> list of steps / commands to test, whenever OpenCL issues or segfaults
>> appear.
>>
>> See the tip version of README:
>> https://sourceforge.net/p/octave-ocl/code/ci/default/tree/README
>>
>> This description reflects some experience made, but can still be
>> considered (advanced) work in progress.
>>
>> Can you try and comment?
>
> I would.  But its not clear to me how to use this from source.
>
> A while ago I filed https://sourceforge.net/p/octave-ocl/tickets/4/
>
> I assume I put all the .c  and .h files in src/ and the .m files in inst/ ?
>
> Also, the number of developers on this list running 4.2 is probably
> shrinking.  I can do it with mtmiller's docker images but currently not
> working on my system...
>
> Colin

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
In reply to this post by Matthias W. Klein
Colin,

do you see any GPL3 license issues with OCL dynamically linking to any
free or non-free OpenCL library?

To my understanding, these are collectively "System Libraries" (maybe
because of the existence of Mesa / Clover), but your assessment will be
highly valued!

Thanks,
Matt


On 26.04.2019 22:22, Matthias W. Klein wrote:

> 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)

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Mike Miller-4
On Sat, May 25, 2019 at 16:57:08 +0200, Matthias W. Klein wrote:
> do you see any GPL3 license issues with OCL dynamically linking to any
> free or non-free OpenCL library?

I don't, as long as there are free OpenCL stacks that do work. It seems
very similar to the situation with non-free OpenGL drivers. Is that a
good comparison, are there any major differences between OpenGL and
OpenCL with respect to the various free and non-free implementations?

> To my understanding, these are collectively "System Libraries" (maybe
> because of the existence of Mesa / Clover), but your assessment will be
> highly valued!

IMHO this doesn't really matter. The way I read it, the System Library
exception is a way of saying your program can depend on POSIX and it
doesn't matter whether the operating system is GNU or Solaris or macOS.

For OpenGL and OpenCL, I don't think it matters whether they can be
called System Libraries or not. What matters is that your programs works
with any free OpenCL stacks that are under compatible free licenses. If
the user opts to drop in a different non-free OpenCL driver, that's
their choice.

IANAL, none of this is legal advice, but if you want legal advice, maybe
ask the FSF Licensing team [1].

[1]: https://www.fsf.org/licensing/

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
Thanks, Mike.

I think the situation for OpenGL and OpenCL is comparable.

@Colin: Do you support Mike's statements?

Matt

On 25.05.2019 21:46, Mike Miller wrote:

> On Sat, May 25, 2019 at 16:57:08 +0200, Matthias W. Klein wrote:
>> do you see any GPL3 license issues with OCL dynamically linking to any
>> free or non-free OpenCL library?
>
> I don't, as long as there are free OpenCL stacks that do work. It seems
> very similar to the situation with non-free OpenGL drivers. Is that a
> good comparison, are there any major differences between OpenGL and
> OpenCL with respect to the various free and non-free implementations?
>
>> To my understanding, these are collectively "System Libraries" (maybe
>> because of the existence of Mesa / Clover), but your assessment will be
>> highly valued!
>
> IMHO this doesn't really matter. The way I read it, the System Library
> exception is a way of saying your program can depend on POSIX and it
> doesn't matter whether the operating system is GNU or Solaris or macOS.
>
> For OpenGL and OpenCL, I don't think it matters whether they can be
> called System Libraries or not. What matters is that your programs works
> with any free OpenCL stacks that are under compatible free licenses. If
> the user opts to drop in a different non-free OpenCL driver, that's
> their choice.
>
> IANAL, none of this is legal advice, but if you want legal advice, maybe
> ask the FSF Licensing team [1].
>
> [1]: https://www.fsf.org/licensing/
>

Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Colin Macdonald-2
On 2019-05-26 1:11 p.m., Matthias W. Klein wrote:
> Thanks, Mike.
>
> I think the situation for OpenGL and OpenCL is comparable.
>
> @Colin: Do you support Mike's statements?

I am also not a lawyer but I think I agree.

 > On 25.05.2019 21:46, Mike Miller wrote:
 >> For OpenGL and OpenCL, I don't think it matters whether they can be
 >> If the user opts to drop in a different non-free OpenCL driver,
 >> that's their choice.

Yeah, unless they *ship* your library with it linked against a
proprietary OpenCL lib.  Then maybe it gets blurry (well not for me:
*I'd* consider that a GPL violation).  But even they, they are doing
something wrong, not you.

Put another way, the fact that someone else *could* do something with
your software that would be a GPL violation by no means stops you from
developing it.

Anyway, just my opinions not legal advice (of course),
Colin


Reply | Threaded
Open this post in threaded view
|

Re: New Octave package "OCL" providing OpenCL support

Matthias W. Klein
Colin, Mike,

thank you for sharing your opinions - which is what I meant to ask for.

They agree with mine: At least one OpenCL driver is free (Mesa), so all
drivers may be links against, but no (non-free) driver may be shipped
with the package (holds for the OCL repo). Everything as is with OpenGL
since long.

Although I am also not a lawyer, this settles the question for me on
this list.

Matt

On 27.05.2019 06:36, Colin Macdonald wrote:

> On 2019-05-26 1:11 p.m., Matthias W. Klein wrote:
>> Thanks, Mike.
>>
>> I think the situation for OpenGL and OpenCL is comparable.
>>
>> @Colin: Do you support Mike's statements?
>
> I am also not a lawyer but I think I agree.
>
>> On 25.05.2019 21:46, Mike Miller wrote:
>>> For OpenGL and OpenCL, I don't think it matters whether they can be
>>> If the user opts to drop in a different non-free OpenCL driver,
>>> that's their choice.
>
> Yeah, unless they *ship* your library with it linked against a
> proprietary OpenCL lib.  Then maybe it gets blurry (well not for me:
> *I'd* consider that a GPL violation).  But even they, they are doing
> something wrong, not you.
>
> Put another way, the fact that someone else *could* do something with
> your software that would be a GPL violation by no means stops you from
> developing it.
>
> Anyway, just my opinions not legal advice (of course),
> Colin
>

Reply | Threaded
Open this post in threaded view
|

OCL package 0.9.2 released

Matthias W. Klein
In reply to this post by Matthias W. Klein
Hi Octave folks,

a new release of the OCL package providing OpenCL support is available
[1].  It features improved starting-up and error reporting, improved
Matlab compatibility, and extended documentation (getting started,
troubleshooting).  I also encourage all previous users (successsful or
unsuccessful users) to upgrade.  Feedback is welcome, by e-mail or
project ticket.

Matt

[1] https://sourceforge.net/p/octave-ocl/