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
Interesting! Because of the CUBLAS kernel, shared memory is initialized, resulting in us not generating a new key at the start of the rand kernel. In addition, the updates to rng.ctr1 somehow are not visible in the different kernel launches (shared memory never wasn't guaranteed to behave like this, but it's weird that a CUBLAS kernel affects this), resulting in identical key and counter entries, and as a result deterministic numbers being generated.
I fixed this in #2035 by passing a unique seed from the host. Even in the case that updates to ctr1 are lost, we're using a new key now, so are getting new numbers.
Describe the bug
Sometimes calling
rand
in a CUDA kernel results in deterministic behavior. This happens when the kernel call is preceded by a call to a CUBLAS method.To reproduce
The following code works as expectedThe Minimal Working Example (MWE) for this bug:
I get an output
Calling
gemv_strided_batched!
before the kernel call results in deterministic behavior in subsequent kernel callsIn this case a get a result like
Manifest.toml
Expected behavior
The pseudorandom numbers in sebsequent iterations are different.
Version info
Details on Julia:
Details on CUDA:
The text was updated successfully, but these errors were encountered: