Open wence- opened 2 years ago
The silently bad behaviour was turned into actual logic_error
s in #10850, it would still be possible to support more fortran-order or broadcasted inputs if desired.
This issue has been labeled inactive-30d
due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d
if there is no activity in the next 60 days.
This issue has been labeled inactive-90d
due to no recent activity in the past 90 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed.
Related to #10754, the current implementation of
from_dlpack
requires unit-stride fortran order, and produces appropriate error messages in the unsupported casesConsider
Since
from_dlpack
copies in all cases right now, I think that things can be handled like so:cudaMemcpyAsync
one column at a timestd::fill
for the 1D case, just getting the strides right for the 2D casecudaMemcpy2DAsync
with appropriate choices of pitch and stride for the source arrayHowever, I'm not really sure of the performance implications of these choices, and if the current approach of producing an error and requiring that the caller copy to contiguous fortran-order first before calling
from_dlpack
is not better. For example, for case 4 is it faster to copy to a contiguous buffer first rather than copying column by column?