# Device RNG - Passes BigCrush

**URL:** <https://discourse.julialang.org/t/device-rng-passes-bigcrush/120976>\
**Category:** GPU\
**Created:** [October 6, 2024, 3:41pm UTC](https://discourse.julialang.org/t/device-rng-passes-bigcrush/120976 "2024-10-06T15:41:29Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [October 17, 2024, 9:35am UTC](https://discourse.julialang.org/t/device-rng-passes-bigcrush/120976/13 "2024-10-17T09:35:32Z")

</div>

> [@MrBelette](#):
>
> At first I was confused as to why you had set up shared memory for 32 warps when rand! only using a single warp (and hence there is only 1 warpId). Or why counter 1 is incremented in rand when counter 2 is being used to set the parallel substreams. Incrementing counter 1 for this version of rand! is superfluous. But, of course, a user could create their own kernel with up to 32 warps and rand could be called multiple times in a thread, so both items are needed.

Yeah, the whole RNG was initially designed and implemented only for device-side use, where we have to support any launch configuration. The host-side RNG wrapper around it only materialized after that.

> [@MrBelette](#):
>
> The user would need to increment counter 1 correctly after a kernel call, as you’ve done in rand! (although, in this case where only one call to rand per thread is being made, I think you could safely increment it by 1 rather than length(A)), to ensure that the same counter state isn’t used in subsequent kernel calls.

Maybe I’m misunderstanding, but the user shouldn’t have to do anything. By default, when not explicitly setting the counter [as the RNG kernel does](https://github.com/JuliaGPU/CUDA.jl/blob/fef47658abec6fff310d3436e98c66ee978d209e/src/random.jl#L50-L51), the generated code will seed the device-side RNG using a random seed that’s [fed from the CPU side](https://github.com/JuliaGPU/CUDA.jl/blob/fef47658abec6fff310d3436e98c66ee978d209e/src/compiler/execution.jl#L271-L273), and is unique for every kernel invocation.

> [@Palli](#):
>
> Why did you choose Philox2x32?

It was suggested to me, in [CUDA.jl v3.0 - #6 by oschulz](https://discourse.julialang.org/t/cuda-jl-v3-0/58921/6). Being counter-based helped fix the issues we were having with the previous Tausworthe generator. Also, having an existing Julia implementation in Random123.jl helped implementing it.

---

_[View the full topic](https://discourse.julialang.org/t/device-rng-passes-bigcrush/120976)._