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
Hi! First, thanks for vuh, it makes lots of stuff much easier. :]
I noticed that in case of copying into host-inaccessible memory through the cached memory, fromHost does not check that the iterator range used to construct the buffer (ie. distance between begin and end) is really equal to the actual array size that gets transferred (which is size_bytes()).
This causes really nasty failures (eg literal reboots on some certain linux drivers) and is IMO particularly surprising -- if given a smaller range, I'd expect that just the starting piece of memory is filled, as with std::copy.
I can make a PR to "fix" this, just wondering which fix would be best:
document this properly and leave the handling to the users?
assert() that iterator range matches the array size?
behave "as reasonably as possible" and just copy min(end-begin, size()) elements to avoid problems? (I guess this behavior is the least surprising thus most reasonable, asking mainly because I'm not sure whether it would break any other expectations.)
Thanks for suggestions!
The text was updated successfully, but these errors were encountered:
exaexa
changed the title
assert that fromHost does not copy unmapped memory
assert that fromHost does not copy non-allocated memory
Jul 24, 2021
Thanks for catching this. I guess the third option (behave "as reasonably...") would be the right way to fix this (and this is actually how the device-to-host copy works in vuh2 branch which I did not have time/enough-motivation to release but I encourage you to use that instead).
Merge requests are welcome, although I may be slow to respond.
Hi! First, thanks for vuh, it makes lots of stuff much easier. :]
I noticed that in case of copying into host-inaccessible memory through the cached memory,
fromHost
does not check that the iterator range used to construct the buffer (ie. distance betweenbegin
andend
) is really equal to the actual array size that gets transferred (which issize_bytes()
).The problem is around here, possibly also in other places:
https://github.com/Glavnokoman/vuh/blob/master/src/include/vuh/arr/deviceArray.hpp#L113
This causes really nasty failures (eg literal reboots on some certain linux drivers) and is IMO particularly surprising -- if given a smaller range, I'd expect that just the starting piece of memory is filled, as with
std::copy
.I can make a PR to "fix" this, just wondering which fix would be best:
min(end-begin, size())
elements to avoid problems? (I guess this behavior is the least surprising thus most reasonable, asking mainly because I'm not sure whether it would break any other expectations.)Thanks for suggestions!
The text was updated successfully, but these errors were encountered: