OCL package 1.0.0 released

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

OCL package 1.0.0 released

Matthias W. Klein
Hi Octave folks,

a new release of the OCL package providing OpenCL support for
parallelized calculations (including GPGPU) is available [1], version
1.0.0 .

It is the first package release which is fully compatible with all
recently released octave versions.  (Thanks to the "communications"
package, I learned a crucial octave programming technique.)  A summary
of all important user-visible changes is available online [2].

Users and developers can choose to either download and install the
package tarball [3], or clone the repo [4] and use 'make dist' and other
Makefile targets for local testing.

Feedback is welcome, by e-mail or project ticket.

@Octave Forge maintainers: Can the package become officially
affiliated to Octave Forge, after your fair testing?

Best,
Matt

[1] https://sourceforge.net/p/octave-ocl/
[2] https://sourceforge.net/p/octave-ocl/code/ci/default/tree/NEWS
[3] https://sourceforge.net/projects/octave-ocl/files/latest/download
[4] hg clone http://hg.code.sf.net/p/octave-ocl/code octave-ocl-code

Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

Matthias W. Klein
> Dear Matthias,
>
> I have managed to install your package but am getting the error
> message below.
>
> I am using ubuntu linux 14.04LTS. I am not sure whether opencl
> is completely installed?
>
> I do not know what the correct name of the opencl package is for
> ubuntu 14.04 so that I can specify this on the synaptic package
> manager?
>
> How do I specify that your package (or opencl) should use the
> core i7 on my machine?
>
> My machine also has a radeon graphics card (but I do not know
> how to determine the exact model number and specifications of
> the radeon graphics card, etc).
>
> How do I specify that your package (or opencl) should rather use
> the radeon graphics card for the computations (as this may be
> faster)?
>
> Thank you very much for any assistance with regard to the above.
>
> Best wishes,
> Constantinos
>
>
> octave:24> ocl_tests
> Testing ocl_constant function...
> Testing ocl_lib function...
> Testing ocl_context function...
> ocl: calling OpenCL function 'clGetPlatformIDs'
>   returned error 'CL_PLATFORM_NOT_FOUND_KHR' (-1001).
>   Please check your OpenCL installation.
> error: ocl_context: OpenCL function call error
> error: called from:
> error:   /home/cfrangos/octave/ocl-1.0.0/ocl_tests.m at line 85, column 11
> octave:24>
>
>
>
>
Constantinos,

the OCL package comes with a README file, in the doc/ subdirectory.  You
can use the octave command 'pkg list' to find your directory where the
package is installed, in order to get to the file.  The README contains
comprehensive info on using the package, including a "troubleshooting"
section distinguishing OpenCL installation issues from OCL issues.

 From your messages, I estimate that your system contains an OpenCL
library (=the "ICD loader"), but no specific hardware device drivers (or
none correctly installed; see also your /etc/OpenCL/vendors/* in Linux).
  You can find lots of infos on OpenCL Linux driver installation in the web.

Once you have your drivers accessible, you can use the OCL function
'ocl_context' to list and choose your hardware to use - type 'help
ocl_context' to see its syntax help.

Best,
Matt


Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

Constantinos Frangos
Hi Matthias,

Thanks for the detailed response.

Any help with the following would be appreciated.

(1) The directory /etc/OpenCL/vendors/ contains only one file
called intel.icd and the contents is as follows.
/usr/lib/beignet/libcl.so

(2) I tried the command ocl_context ("get_resources") and the
output is given below. Not clear what this indicates?

(3) Please provide some information on the relevant opencl linux
hardware driver for 4th generation intel core i7 and I will try to
download this from the internet.

(The information I found on the internet was not clear? The easiest
would be to locate the name of the relevant ubuntu 14.04 package
on the synaptic package manager.)

Thank you.

Best regards,
Constantinos

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

octave:32> d = ocl_context ("get_resources")
d =

  scalar structure containing the fields:

    platforms =
    {
      [1,1] =

        scalar structure containing the fields:

          platform_index = 0
          name = Experiment Intel Gen OCL Driver
          version = OpenCL 1.1 beignet 0.3
          profile = FULL_PROFILE
          vendor = Intel
          extensions = cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store
cl_khr_icd

    }

On 8/12/19, Matthias W. Klein <[hidden email]> wrote:

>> Dear Matthias,
>>
>> I have managed to install your package but am getting the error
>> message below.
>>
>> I am using ubuntu linux 14.04LTS. I am not sure whether opencl
>> is completely installed?
>>
>> I do not know what the correct name of the opencl package is for
>> ubuntu 14.04 so that I can specify this on the synaptic package
>> manager?
>>
>> How do I specify that your package (or opencl) should use the
>> core i7 on my machine?
>>
>> My machine also has a radeon graphics card (but I do not know
>> how to determine the exact model number and specifications of
>> the radeon graphics card, etc).
>>
>> How do I specify that your package (or opencl) should rather use
>> the radeon graphics card for the computations (as this may be
>> faster)?
>>
>> Thank you very much for any assistance with regard to the above.
>>
>> Best wishes,
>> Constantinos
>>
>>
>> octave:24> ocl_tests
>> Testing ocl_constant function...
>> Testing ocl_lib function...
>> Testing ocl_context function...
>> ocl: calling OpenCL function 'clGetPlatformIDs'
>>   returned error 'CL_PLATFORM_NOT_FOUND_KHR' (-1001).
>>   Please check your OpenCL installation.
>> error: ocl_context: OpenCL function call error
>> error: called from:
>> error:   /home/cfrangos/octave/ocl-1.0.0/ocl_tests.m at line 85, column
>> 11
>> octave:24>
>>
>>
>>
>>
> Constantinos,
>
> the OCL package comes with a README file, in the doc/ subdirectory.  You
> can use the octave command 'pkg list' to find your directory where the
> package is installed, in order to get to the file.  The README contains
> comprehensive info on using the package, including a "troubleshooting"
> section distinguishing OpenCL installation issues from OCL issues.
>
>  From your messages, I estimate that your system contains an OpenCL
> library (=the "ICD loader"), but no specific hardware device drivers (or
> none correctly installed; see also your /etc/OpenCL/vendors/* in Linux).
>   You can find lots of infos on OpenCL Linux driver installation in the
> web.
>
> Once you have your drivers accessible, you can use the OCL function
> 'ocl_context' to list and choose your hardware to use - type 'help
> ocl_context' to see its syntax help.
>
> Best,
> Matt
>
>

Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

PhilipNienhuis
In reply to this post by Matthias W. Klein
Matthias W. Klein wrote

> Hi Octave folks,
>
> a new release of the OCL package providing OpenCL support for
> parallelized calculations (including GPGPU) is available [1], version
> 1.0.0 .
>
> It is the first package release which is fully compatible with all
> recently released octave versions.  (Thanks to the "communications"
> package, I learned a crucial octave programming technique.)  A summary
> of all important user-visible changes is available online [2].
>
> Users and developers can choose to either download and install the
> package tarball [3], or clone the repo [4] and use 'make dist' and other
> Makefile targets for local testing.
>
> Feedback is welcome, by e-mail or project ticket.

I just tested ocl-1.0 on a cross-built dev Octave 6.0.0 on my Windows 7 box
with 2 graphics HW, i.e., built-in Intel plus an NVidia graphics card.
Results: ocl_tests works fine & gives no errors and the example in the
doc/README works fine compared to mimicking the commands in Octave.

While installing/building the package I got a LOT of errors along the lines
of:

:
C:/Programs/Octave/OCTAVE~1.0_2/mingw64/bin/mkoctfile-6.0.0.exe --verbose -c
ocl_ov_matrix.cc
g++ -c
-I/home/philip/devel/octdev/mxe/mxe_64b_20190808/usr/x86_64-w64-mingw32/include
-IC:\Progr
ams\Octave\OCTAVE~1.0_2\mingw64\include\octave-6.0.0\octave\..
-IC:\Programs\Octave\OCTAVE~1.0_2\m
ingw64\include\octave-6.0.0\octave
-IC:\Programs\Octave\OCTAVE~1.0_2\mingw64\include   -fopenmp -g
 -O2    ocl_ov_matrix.cc -o ocl_ov_matrix.o
ocl_ov_matrix.cc: In member function 'octave_base_ocl_matrix<AT>*
octave_base_ocl_matrix<AT>::ocl_
index_op(const octave_value_list&, bool)':
ocl_ov_matrix.cc:181:13: warning: 'error_state' is deprecated: [6]: this
variable is obsolete and
always has the value 0 [-Wdeprecated-declarations]
         if (error_state) break;
             ^~~~~~~~~~~
In file included from
c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\oct.h:33
:0,
                 from ocl_octave_versions.h:4,
                 from ocl_ov_matrix.h:37,
                 from ocl_ov_matrix.cc:32:
c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\error.h:551:26:
note: declared
 here
 extern OCTINTERP_API int error_state;
                          ^~~~~~~~~~~
ocl_ov_matrix.cc:190:11: warning: 'error_state' is deprecated: [6]: this
variable is obsolete and
always has the value 0 [-Wdeprecated-declarations]
:

so I'd suggest to update these statements so that ocl-1.0 isn't outdated the
moment that Octave-6.1.0 is released. Perhaps some configure option stuff is
needed for that.

Next try: on the virtualized HW of the VDI clients at work. Maybe maybe it
works.

Nice work, Matthias!

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

Matthias W. Klein
On 20.08.2019 00:08, PhilipNienhuis wrote:

> Matthias W. Klein wrote
>> Hi Octave folks,
>>
>> a new release of the OCL package providing OpenCL support for
>> parallelized calculations (including GPGPU) is available [1], version
>> 1.0.0 .
>>
>> It is the first package release which is fully compatible with all
>> recently released octave versions.  (Thanks to the "communications"
>> package, I learned a crucial octave programming technique.)  A summary
>> of all important user-visible changes is available online [2].
>>
>> Users and developers can choose to either download and install the
>> package tarball [3], or clone the repo [4] and use 'make dist' and other
>> Makefile targets for local testing.
>>
>> Feedback is welcome, by e-mail or project ticket.
>
> I just tested ocl-1.0 on a cross-built dev Octave 6.0.0 on my Windows 7 box
> with 2 graphics HW, i.e., built-in Intel plus an NVidia graphics card.
> Results: ocl_tests works fine & gives no errors and the example in the
> doc/README works fine compared to mimicking the commands in Octave.
>
> While installing/building the package I got a LOT of errors along the lines
> of:
>
> :
> C:/Programs/Octave/OCTAVE~1.0_2/mingw64/bin/mkoctfile-6.0.0.exe --verbose -c
> ocl_ov_matrix.cc
> g++ -c
> -I/home/philip/devel/octdev/mxe/mxe_64b_20190808/usr/x86_64-w64-mingw32/include
> -IC:\Progr
> ams\Octave\OCTAVE~1.0_2\mingw64\include\octave-6.0.0\octave\..
> -IC:\Programs\Octave\OCTAVE~1.0_2\m
> ingw64\include\octave-6.0.0\octave
> -IC:\Programs\Octave\OCTAVE~1.0_2\mingw64\include   -fopenmp -g
>  -O2    ocl_ov_matrix.cc -o ocl_ov_matrix.o
> ocl_ov_matrix.cc: In member function 'octave_base_ocl_matrix<AT>*
> octave_base_ocl_matrix<AT>::ocl_
> index_op(const octave_value_list&, bool)':
> ocl_ov_matrix.cc:181:13: warning: 'error_state' is deprecated: [6]: this
> variable is obsolete and
> always has the value 0 [-Wdeprecated-declarations]
>          if (error_state) break;
>              ^~~~~~~~~~~
> In file included from
> c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\oct.h:33
> :0,
>                  from ocl_octave_versions.h:4,
>                  from ocl_ov_matrix.h:37,
>                  from ocl_ov_matrix.cc:32:
> c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\error.h:551:26:
> note: declared
>  here
>  extern OCTINTERP_API int error_state;
>                           ^~~~~~~~~~~
> ocl_ov_matrix.cc:190:11: warning: 'error_state' is deprecated: [6]: this
> variable is obsolete and
> always has the value 0 [-Wdeprecated-declarations]
> :
>
> so I'd suggest to update these statements so that ocl-1.0 isn't outdated the
> moment that Octave-6.1.0 is released. Perhaps some configure option stuff is
> needed for that.
>
> Next try: on the virtualized HW of the VDI clients at work. Maybe maybe it
> works.
>
> Nice work, Matthias!
>
> Philip
Philip,

thanks for your dedicated evaluation and motivating comment.

The last months, I worked on making the OCL project compatible with
released versions of octave as prio #1. Doing the same with the octave
dev has been on my mind - as one of several ideas in which direction OCL
should grow in the future, maybe as the most important of these. (I
will, however, need to setup a new dedicated environment for that, in
short, so don't expect it tomorrow.)

Your tests clearly show very promising results with the octave dev, very
appreciated. And also show only little work left, probably only a few
encapsulations with preprocessor directives using an extended
ocl_octave_versions.h

In order to clarify for me: What difference will it make to have a
dev-compatible ocl package, what aspects are relevant to you octave
maintainers in practice for the package? Where do you see it in relation
to the octave (forge) project?

Please do keep me posted on you further tests as announced.

Best, Matt

Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

PhilipNienhuis
Matthias W. Klein wrote:

> On 20.08.2019 00:08, PhilipNienhuis wrote:
>> Matthias W. Klein wrote
>>> Hi Octave folks,
>>>
>>> a new release of the OCL package providing OpenCL support for
>>> parallelized calculations (including GPGPU) is available [1], version
>>> 1.0.0 .
>>>
>>> It is the first package release which is fully compatible with all
>>> recently released octave versions.  (Thanks to the "communications"
>>> package, I learned a crucial octave programming technique.)  A summary
>>> of all important user-visible changes is available online [2].
>>>
>>> Users and developers can choose to either download and install the
>>> package tarball [3], or clone the repo [4] and use 'make dist' and other
>>> Makefile targets for local testing.
>>>
>>> Feedback is welcome, by e-mail or project ticket.
>>
>> I just tested ocl-1.0 on a cross-built dev Octave 6.0.0 on my Windows
>> 7 box
>> with 2 graphics HW, i.e., built-in Intel plus an NVidia graphics card.
>> Results: ocl_tests works fine & gives no errors and the example in the
>> doc/README works fine compared to mimicking the commands in Octave.
>>
>> While installing/building the package I got a LOT of errors along the
>> lines
>> of:
>>
>> :
>> C:/Programs/Octave/OCTAVE~1.0_2/mingw64/bin/mkoctfile-6.0.0.exe
>> --verbose -c
>> ocl_ov_matrix.cc
>> g++ -c
>> -I/home/philip/devel/octdev/mxe/mxe_64b_20190808/usr/x86_64-w64-mingw32/include
>>
>> -IC:\Progr
>> ams\Octave\OCTAVE~1.0_2\mingw64\include\octave-6.0.0\octave\..
>> -IC:\Programs\Octave\OCTAVE~1.0_2\m
>> ingw64\include\octave-6.0.0\octave
>> -IC:\Programs\Octave\OCTAVE~1.0_2\mingw64\include   -fopenmp -g
>>  -O2    ocl_ov_matrix.cc -o ocl_ov_matrix.o
>> ocl_ov_matrix.cc: In member function 'octave_base_ocl_matrix<AT>*
>> octave_base_ocl_matrix<AT>::ocl_
>> index_op(const octave_value_list&, bool)':
>> ocl_ov_matrix.cc:181:13: warning: 'error_state' is deprecated: [6]: this
>> variable is obsolete and
>> always has the value 0 [-Wdeprecated-declarations]
>>          if (error_state) break;
>>              ^~~~~~~~~~~
>> In file included from
>> c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\oct.h:33
>>
>> :0,
>>                  from ocl_octave_versions.h:4,
>>                  from ocl_ov_matrix.h:37,
>>                  from ocl_ov_matrix.cc:32:
>> c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\error.h:551:26:
>>
>> note: declared
>>  here
>>  extern OCTINTERP_API int error_state;
>>                           ^~~~~~~~~~~
>> ocl_ov_matrix.cc:190:11: warning: 'error_state' is deprecated: [6]: this
>> variable is obsolete and
>> always has the value 0 [-Wdeprecated-declarations]
>> :
>>
>> so I'd suggest to update these statements so that ocl-1.0 isn't
>> outdated the
>> moment that Octave-6.1.0 is released. Perhaps some configure option
>> stuff is
>> needed for that.
>>
>> Next try: on the virtualized HW of the VDI clients at work. Maybe
>> maybe it
>> works.
>>
>> Nice work, Matthias!
>>
>> Philip
> Philip,
>
> thanks for your dedicated evaluation and motivating comment.
>
> The last months, I worked on making the OCL project compatible with
> released versions of octave as prio #1. Doing the same with the octave
> dev has been on my mind - as one of several ideas in which direction OCL
> should grow in the future, maybe as the most important of these. (I
> will, however, need to setup a new dedicated environment for that, in
> short, so don't expect it tomorrow.)
>
> Your tests clearly show very promising results with the octave dev, very
> appreciated. And also show only little work left, probably only a few
> encapsulations with preprocessor directives using an extended
> ocl_octave_versions.h
>
> In order to clarify for me: What difference will it make to have a
> dev-compatible ocl package, what aspects are relevant to you octave
> maintainers in practice for the package? Where do you see it in relation
> to the octave (forge) project?
>
> Please do keep me posted on you further tests as announced.

A lot of questions, Matthias. I think of myself not so much as a core
dev but rather a contributor and OF package maintainer (io and mapping).

I merely wanted to test the package for you in its current state as you
asked on the ML. Well, it was fun in the limited time I had available.

To be compatible with dev Octave now is primarily a convenience. It will
make sure that you do not have to worry later if 5.2.0 is skipped and
6.1.0 is released instead. As for myself, I always use bleeding edge
Octave, usually not "older" than one or two weeks.
IMO it is always a good thing to try to be compatible with dev Octave,
because when a new Octave is released it usually takes a few months to
get OF packages updated. For end users that is not very motivating. But
admittedly dev Octave can be a moving target.

While testing I got the impression that ocl by itself just provides a
framework to build upon. To do useful things with it user code has to
incorporate its functions, possibly with try/catch around it to follow
another code path in case ocl isn't supported on the local HW. It's not
as if ocl is a mere drop-in replacement for user code, it requires a
little more.
Or did I get that wrong? I only briefly tested a few things.

Anyway, in my opinion ocl is a very useful and promising package. I'd
like to try really big matrices to test if ocl really makes a difference
but that'll have to wait a bit I'm afraid.

Philip







Reply | Threaded
Open this post in threaded view
|

Re: OCL package 1.0.0 released

Matthias W. Klein
On 20.08.2019 23:57, Philip Nienhuis wrote:

> Matthias W. Klein wrote:
>> On 20.08.2019 00:08, PhilipNienhuis wrote:
>>> Next try: on the virtualized HW of the VDI clients at work. Maybe
>>> maybe it
>>> works.
>>>
>>> Nice work, Matthias!
>>>
>>> Philip
>> Philip,
>>
>> thanks for your dedicated evaluation and motivating comment.
>>
>> The last months, I worked on making the OCL project compatible with
>> released versions of octave as prio #1. Doing the same with the octave
>> dev has been on my mind - as one of several ideas in which direction OCL
>> should grow in the future, maybe as the most important of these. (I
>> will, however, need to setup a new dedicated environment for that, in
>> short, so don't expect it tomorrow.)
>>
>> Your tests clearly show very promising results with the octave dev, very
>> appreciated. And also show only little work left, probably only a few
>> encapsulations with preprocessor directives using an extended
>> ocl_octave_versions.h
>>
>> In order to clarify for me: What difference will it make to have a
>> dev-compatible ocl package, what aspects are relevant to you octave
>> maintainers in practice for the package? Where do you see it in relation
>> to the octave (forge) project?
>>
>> Please do keep me posted on you further tests as announced.
>
> A lot of questions, Matthias. I think of myself not so much as a core
> dev but rather a contributor and OF package maintainer (io and mapping).
>
> I merely wanted to test the package for you in its current state as you
> asked on the ML. Well, it was fun in the limited time I had available.
>
> To be compatible with dev Octave now is primarily a convenience. It will
> make sure that you do not have to worry later if 5.2.0 is skipped and
> 6.1.0 is released instead. As for myself, I always use bleeding edge
> Octave, usually not "older" than one or two weeks.
> IMO it is always a good thing to try to be compatible with dev Octave,
> because when a new Octave is released it usually takes a few months to
> get OF packages updated. For end users that is not very motivating. But
> admittedly dev Octave can be a moving target.

Dear Philip and octave maintainers!

Your package testing with dev octave is highly valued, in past and
future, Philip!

My questions about the package compatibility with dev octave was aimed
at all maintainers - also giving you the opportunity to start the
discussion with your assessment (thank you for picking up the ball,
Philip). Your point towards convenience convinces me and fits to my
(previously vague) understanding. Agreed, compatibility is worthwhile
and attractive for the near future.

@Maintainers:
a) So is it that each package release should be tested against a recent
dev octave before release?
b) How is the other way usually handled, with all existing OF packages?
Is it each package maintainer's responsibility to re-achieve package
compatibility after octave release, or is some other way of
collaboration common?
I consider myself a newbie in these respects, thanks for letting me know.

 >
 > While testing I got the impression that ocl by itself just provides a
 > framework to build upon. To do useful things with it user code has to
 > incorporate its functions, possibly with try/catch around it to follow
 > another code path in case ocl isn't supported on the local HW. It's not
 > as if ocl is a mere drop-in replacement for user code, it requires a
 > little more.
 > Or did I get that wrong? I only briefly tested a few things.
 >
 > Anyway, in my opinion ocl is a very useful and promising package. I'd
 > like to try really big matrices to test if ocl really makes a difference
 > but that'll have to wait a bit I'm afraid.

Ocl as "just a framework": If you like to strongly simplify it, yes. As
is all of octave in the first place: The user has to put in code to get
meaningful results which are of value to him/her.

In analogy, at least to a certain extent, this is the purpose of the ocl
package: Give the user the ability to (hopefully) accelerate his/her
code using present hardware. Another analogy is Mathworks' 'gpuArray'
functionality [1], which, as far as documented, must have concerned
somewhat consequently rewriting "all" their core math functions to also
work with this GPU data type (in my interpretation from their doc; I
never had access to Mathworks' parallel computing package for testing).
Well, not fully: They say math functions which shall output complex
numbers must be fed with complex number data as input.

The ocl package implements many math functions and operators for
oclArray data (but surely not as much as the Mathworks package today).
Much octave code can simply be reused with ocl. But I have not tested
what octave functions beyond those in ocl_test.m actually run already today.

What I have done with ocl, for instance, is write a complete Monte Carlo
simulation (with 1e5 to 1e8 particles) in three different ways:
1) pure octave code of ~1000 summed lines,
2) the very same code with ~10 lines added at the beginning/end, to
completely work with ocl math functions and operators, and
3) translating the code to OpenCL C and using 'ocl_program'.
My results were:
a) The OpenCL C code ran almost a factor of 1000 faster than pure octave
code, using a good but old GPU.
b) The code using ocl math functions and operators was slower than
octave, even for large datasets, due to overhead.

This having said, I think the ocl package is very good at the following:

* Provide a detailed infrastructure between octave, the (correctly
installed) OpenCL software and the (chosen) OpenCL hardware.

* Provide best acceleration with user-written OpenCL C code, which is
handled by ocl interactively.

* Provide handy means (functions, operators, indexing) for inspection of
intermediate and end result data.

The package is currently not so efficient or good at:

* Provide efficient acceleration with standard functions and operators.

* Work with complex numbers.

I have had an active look into complex numbers as a future major
extension to ocl.

As to efficient standard functions and operators for re-using octave
code: I have had a few thoughts about more efficient workload
distribution models in ocl_array(_prog).cc, this might be a lightweight
improvement. The alternative would be to fall back onto an established
OpenCL-related math library, like clBLAS(T) [2,3] or MAGMA [4], but,
given the ocl structure, this would raise technical (library calls,
dependencies) and/or licensing questions.

In general, I think the ocl package will never cover all possible
standard functions and operators efficiently, the effort is simply too much.

But I do see, as you do, Philip, that the package can be of great use
for a broad audience of octave users, and have designed the package
correspondingly. I can well imagine ocl to become an OF package, but I
do not know what you maintainers or OF admins require in practice for
this step? (Yes, I have read [5], conform to most of it, and am willing
to discuss the rest. With whom?) Also, the decision community vs.
external package seems crucial. The package itself contains about 10000
lines of C++ code and a few points will have to be adapted slightly in a
concerted action as the octave interface for oct-files evolves. What
procedure is expected or common?

@Maintainers: Who can kindly assist me with the latter questions?

Thanks,
Matt

[1] https://www.mathworks.com/help/parallel-computing/gpuarray.html
[2] https://github.com/clMathLibraries/clBLAS
[3] https://github.com/CNugteren/CLBlast
[4] https://icl.cs.utk.edu/magma/
[5] https://octave.sourceforge.io/developers.php