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. E.g. save('filename', 'non_ocl_variable_1',...)
Last edit: Matthias W. Klein 2021-12-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 and may or may not be reachable at all. For example, with a destroyed OpenCL context, variables may remain valid octave variables, but are no longer backed by any OpenCL resources. Now, if saving OCL data cannot always reach the data, it may never save data. When saving, case distinctions are simply forbidden for transparency reasons. Thus, saving OCL variables ignores any data possibly associated (with a warning, yes, which can be silenced as usual in octave, see "help warning"). This way, saving a workspace which also contains OCL variables is not harmful anymore. If you like to save OCL matrix data, transfer it to octave first (ocl_to_octave).
Consequently, loading a workspace from a file which contains (empty) OCL variables should not be harmful, but will necessarily produce empty, inoperable OCL variables. Loading OCL variables may never trigger setting up an OpenCL context implicitly. Note also that for error-free loading of a workspace containing variables of OCL types, the OCL package must have been loaded in octave (pkg load ocl) to make these types known to octave in the session.
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. E.g. save('filename', 'non_ocl_variable_1',...)
Last edit: Matthias W. Klein 2021-12-01
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 and may or may not be reachable at all. For example, with a destroyed OpenCL context, variables may remain valid octave variables, but are no longer backed by any OpenCL resources. Now, if saving OCL data cannot always reach the data, it may never save data. When saving, case distinctions are simply forbidden for transparency reasons. Thus, saving OCL variables ignores any data possibly associated (with a warning, yes, which can be silenced as usual in octave, see "help warning"). This way, saving a workspace which also contains OCL variables is not harmful anymore. If you like to save OCL matrix data, transfer it to octave first (ocl_to_octave).
Consequently, loading a workspace from a file which contains (empty) OCL variables should not be harmful, but will necessarily produce empty, inoperable OCL variables. Loading OCL variables may never trigger setting up an OpenCL context implicitly. Note also that for error-free loading of a workspace containing variables of OCL types, the OCL package must have been loaded in octave (pkg load ocl) to make these types known to octave in the session.
Related
Commit: [3ed14b]