You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some operations on operators on Ginkgo assume that the executors of all arguments are the same. This does not have to be true, and with the addition of gko::make_temporary_clone helper can usually be solved easily.
BLAS-1 operations on dense matrices are an example of this problem.
The text was updated successfully, but these errors were encountered:
@tcojean this is not needed for the 1.0.0 release? This can break Ginkgo in a very unpleasant way, without any hint to the user about what went wrong...
It should be a very straightforward process (just needs a bit of time): someone should go through all of Ginkgo's public methods, and check the implementation of the ones that have a LinOp (or LinOp subclass) instance as a parameter. If the implementation calls a kernel and passes this parameter to it, without doing anything special to ensure that the executor the kernel is called on matches with the executor of the LinOp instance, instead of passing the original instance, a gko::temporary_clone of it (with the lifetime of the public method's implementation) should be passed instead.
Some operations on operators on Ginkgo assume that the executors of all arguments are the same. This does not have to be true, and with the addition of
gko::make_temporary_clone
helper can usually be solved easily.BLAS-1 operations on dense matrices are an example of this problem.
The text was updated successfully, but these errors were encountered: