Activity for Matthias W. Klein
-
Matthias W. Klein committed [b45830] on ocl
Tagged release-1.2.4
-
upgrade package version to 1.2.4
-
Tagged release-1.2.4
-
upgrade package version to 1.2.4
-
inst/ocl_tests.m: add typeinfo test
-
inst/ocl_tests.m: simplify type comparison
-
maint: update copyright dates
-
src/ocl_ov_matrix_ops.cc: avoid calling assert()
-
Tagged release-1.2.3
-
upgrade package version to 1.2.3
-
src/ocl_program.cc: enclose CL kernel calls with clEnqueueBarrier twice
-
ocl_tests.m: include output of elapsed time
-
maint: update copyright dates
-
[maint] convert project back to Makefile project (from minimal autoconf project)
-
Tagged release-1.2.2
-
upgrade package version to 1.2.2
-
maint: update copyright dates
-
Use macros for template classes from octave if defined there
-
Tagged release-1.2.1
-
upgrade package version to 1.2.1
-
src/ocl_array_prog.cc: use correct preprocessor directive
-
maint: reformat copyright comments
-
maint: update more copyright dates
-
maint: update copyright dates
-
add (generated) ocl matrix method files to repo
-
add degree-based method files to @ocl_double and @ocl_single
-
ocl.pro: adapt to autoconf project (addendum to a580e0389e4b)
-
src/ocl_program.h: replace 12 occurrences of Array<>.fortran_vec() by .data()
-
inst/oclArray.m: include conversion of "double_range" type
-
remove src/Makefile from repo (addendum to a580e0389e4b)
-
[maint] convert project to minimal autoconf project (from Makefile project)
-
[maint] remove dead code for unsupported octave versions < 4.2.0
-
Tagged release-1.2.0
-
ocl 1.2.0 release
-
Upgraded package version to 1.2.0
-
DESCRIPTION: shorten Description
-
maint: update copyright dates
-
Trigonometry functions in degrees not linked
-
I implemented logical indexing with scalar assignment in OCL with commit 944515. This also makes degree-based trigonometric functions and the like usable with OCL matrices. This feature becomes available with the next OCL release (supposedly 1.2.0). Closing this ticket.
-
I implemented logical indexing with scalar assignment in OCL with commit 944515, following the second approach described above (with flag), for the reasons stated there. The feature will become available with the next OCL release (supposedly 1.2.0).
-
inst/ocl_tests.m: add tests for degree-based trigonometric functions
-
add OCL matrix logically indexed assignment with a scalar value
-
add OCL matrix flag indicating logical result data
-
add "fix" OCL matrix method
-
I am sorry if my earlier comment was somewhat misleading. What I meant in particular is that the degree-based trigonometric functions, along with many other trigonometric and hyperbolic functions, are defined in octave already and do not need to be redefined. More specifically, these ~25 functions are provided in octave as individual m-files (usually in a directory "octave-root/share/octave/x.x.x/m/elfun/"), and not in any octave C++ code. What is lacking in OCL to make these octave m-files work...
-
I am sorry if my earlier comment was somewhat misleading. What I meant in particular is that the degree-based trigonometric functions, along with many other trigonometric and hyperbolic functions, are defined in octave already and do not need to be redefined. More specifically, these ~25 functions are provided in octave as individual m-files (usually in a directory "octave-root/share/octave/x.x.x/m/elfun/"), and not in any octave C++ code. What is lacking in OCL to make these octave m-files work...
-
I am sorry if my earlier comment was somewhat misleading. What I meant in particular is that the degree-based trigonometric functions, along with many other trigonometric and hyperbolic functions, are defined in octave already and do not need to be redefined. More specifically, these ~25 functions are provided in octave as individual m-files (usually in a directory "octave-root/share/octave/x.x.x/m/elfun/"), and not in any octave C++ code. What is lacking in OCL to make these octave m-files work...
-
I am coming back to the case of logical indexing with scalar assignment (e.g., ocl_data_matrix(ocl_logical_matrix) = scalar). (All other cases of logical indexing are forbidden in OCL, see above, since octave cannot know the required OCL matrix sizes.) Even for this very limited use case, OCL would be required to implement matrices in a manner which allows to distinguish whether an OCL matrix used for indexing is meant to be a logical matrix or a matrix holding index values. After profound thinking,...
-
My recommendation for this case is to use one of the following, instead of "A(A<0)=0": A *= (A>=0), or A = max (A, 0), or A = max (0, A) The last option, with max(0,A), will be supported by OCL version >= 1.2.0 (fixed in repo by commit [da82fd]). As we discussed elsewhere, the inversion error you describe was due to an OpenCL driver error and was already fixed by a workaround in OCL in the 1.1.1 update.
-
My recommendation for this case is to use one of the following, instead of "A(A<0)=0": A *= (A>=0), or A = max (A, 0), or * A = max (0, A) The last option, with max(0,A), will be supported by OCL version >= 1.2.0 (fixed in repo by commit [da82fd]). As we discussed elsewhere, the inversion error you describe was due to an OpenCL driver error and was already fixed by a workaround in OCL in the 1.1.1 update.
-
My recommendation for this case is to use one of the following, instead of "A(A<0)=0": A *= (A>=0), or A = max (A, 0), or * A = max (0, A) The last option, with max(0,A), will be supported by OCL version >= 1.2.0 (fixed in repo by commit [da82fd]). As we discussed elsewhere, the inversion error you describe was due to an OpenCL driver error and was already fixed by a workaround in OCL in the 1.1.1 update.
-
My recommendation for this case is to use one of the following, instead of "A(A<0)=0": A = (A>=0), or A = max (A, 0), or A = max (0, A) The last option, with "max(0,A)", will be supported by OCL version >= 1.2.0 (fixed in repo by commit [da82fd]). As we discussed elsewhere, the inversion error you describe was due to an OpenCL driver error and was already fixed by a workaround in OCL in the 1.1.1 update.
-
Problem: If you declared oclArray variable on your workspace, then it would be problem when you save, e.g., save('A'), the whole workspace with error: octave_base_value::save_ascii(): wrong type argument 'ocl matrix'. This will cause a problem for not all workspace variables are saved. Then, when you load the workspace after a new octave instance. You will have the same error and the problem for some of the variables are missing. Workaround: save your variable of interest instead of the whole workspace....
-
The error encountered when saving / loading (partial) workspaces containing OCL variables is fixed with commit [3ed14b] and will be available in the next release (probably 1.2.0). Note, however, that no general saving / loading of OCL data can be implemented. Rather, OCL data (matrices or programs) are simply ignored, or, to be more precise, are treated as if empty or inoperable, when saved. This is a strong requirement, since the OCL data in question is generally strongly dependent on (OpenCL) context...
-
maint: make root Makefile targets "lrun" and "lcheck" use directory specifications independent of OS
-
extend OCL matrix methods "min" and "max" to case with scalar first argument
-
maint: adapt root Makefile targets "lrun" and "lcheck" to depend on temporary PKG_ADD equivalent
-
upgrade calls to functions deprecated in octave 6
-
adapt dummy save / load stubs for octave 6
-
add dummy save / load functionality to OCL variables (to avoid breaking workspace saving / loading)
-
Makefile: Simplify test commands.
-
Add 2 Makefile targets for testing with only local incremental compilation
-
maint: rearrange repo directory structure, introduce standard root Makefile
-
Done tagging. Thank you again, Olaf, for reviewing, and John and Philip for testing!
-
Tagged release-1.1.1
-
@lostbard: Thank you for testing. As to the compiler warning: I could not reproduce it directly myself, using the systems and octave versions I mentioned above, even with verbose mode installation (but I do not have an octave dev/6.0 environment on Windows). However, as a temporary test, I compiled the package sources with -Wall with these configurations. This resulted in about 20 places in the ocl code deserving changes to get rid of the encountered flaws. The warning you mention is taken care of...
-
Well, lostbard/JohnD successfully did tests (see his second post [1] above)... [1] https://sourceforge.net/p/octave/package-releases/399/#dda5
-
I have also successfully tested with octave version 5.1.90 .
-
@Philip: Did you install the original submit or the tarball I posted here today, 30 minutes before your post? Maybe the messages have been crossing each other. The new tarball should IMHO not cause compiler warnings. - Only relevant if you used the latest tarball: Which compiler warnings did you encounter? As to pkg's warning about the doc_cache: I noticed that this message shows with several packages and some systems. I have studied the code of pkg.m and its dependents but currently I still do not...
-
Thank you for testing. As to the compiler warning: I could not reproduce it directly myself, using the systems and octave versions I mentioned above, even with verbose mode installation (but I do not have an octave dev/6.0 environment on Windows). However, as a temporary test, I compiled the package sources with -Wall with these configurations. This resulted in about 20 places in the ocl code deserving changes to get rid of the encountered flaws. The warning you mention is taken care of by adding...
-
Thank you for testing. As to the compiler warning: I could not reproduce it directly myself, using the systems and octave versions I mentioned above, even with verbose mode installation (but I do not have an octave dev/6.0 environment on Windows). However, as a temporary test, I compiled the package sources with -Wall with these configurations. This resulted in about 20 places in the ocl code deserving changes to get rid of the encountered flaws. The warning you mention is taken care of by adding...
-
Prevent potential GCC compiler warnings
-
As stated in the README and oclArray help text, there are and will be restrictions on built-in operations with OCL matrices. The file ocl_tests.m states what is possible. This having said, "logical indexing" (e.g. expressions like data_matrix(logic_matrix) ) is generally not defined in ocl. The reason for this, as is with most of the mentioned restrictions, is of technical nature: As the octave command C(A<0) would be processed on the CPU, it cannot be known how many elements of C are actually involved...
-
Thanks for the feedback. The degree-based trigonometric funtions are defined in octave, but not in OpenCL C. Generally, the ocl package is aimed at functions defined in both languages, at least to a certain extent. Internal to octave, there is also no mechanism to link the two languages in an analogous way as the radian-based ("mapping") functions. So, yes, there are (also) technical reasons for this, so please don't build your hopes up.
-
The degree-based trigonometric funtions are defined in octave, but not in OpenCL C. Generally, the ocl package is aimed at functions defined in both languages, at least to a certain extent. Internal to octave, there is also no mechanism to link the two languages in an analogous way as the radian-based ("mapping") functions. So, yes, there are (also) technical reasons for this, so please don't build your hopes up.
-
ocl-1.1.1 release
-
Minor adaptions to support older Intel GPU OpenCL drivers
-
Upgraded package version to 1.1.1
-
DESCRIPTION: Add project URLs
-
Correct typos in help strings
-
maint: Update copyright dates
-
Tagged release-1.1.0
-
DESCRIPTION, NEWS, README: Upgraded package version to 1.1.0
-
ocl_tests.m: raised tolerances for numeric tests
-
add an OpenCL memory object manager (reducing driver calls for performance)
-
add Makefile target 'release', creating md5sum file
-
maint: dos2unix Makefile (strip CR at line ends)
-
maint: remove execute permission bit of some .cc and .h files
-
remove references to octave's "error_state" variable
-
adaptions for higher octave versions and complex data
-
ocl_array.h/cc+ocl_array_prog.cc+ocl_ov_matrix.cc+ocl_ov_matrix_ops.cc: bugfixes for complex data
-
ocl_tests.m: added tests for complex ocl data
-
Makefile+ocl_array.h/cc+ocl_ov_matrix.h/cc: introduction of 'complex()' function for ocl matrices
-
oclArray.m+ocl_to_octave.m: adaptions for complex numbers (code and tests)
-
oclArray.m+ocl_ov_matrix.cc+ocl_ov_program.cc: updated doc regarding complex data
-
ocl_array.h/cc+ocl_ov_matrix_ops.cc+ocl_ov_program.cc: many more adaptions for complex numbers
-
ocl_array.cc+ocl_array_prog.h/cc+ocl_ov_matrix_ops.cc: more incremental adaptions for complex
-
ocl_array.h/cc+ocl_ov_matrix.h/cc: more incremental adaptions for complex numbers
-
ocl_array.h/cc+ocl_ov_matrix_ops.cc: more incremental adaptions for complex numbers
-
ocl_array.cc+ocl_array_prog.cc+ocl_ov_matrix.h+ocl_ov_matrix_fcns.cc+ocl_ov_matrix_ops.cc+ocl_ov_program.cc:
1 >
