Gliden64: Usage of cryptographically secure RNG for MinGW in NoiseTextures

[m4xw]

Hey @gonetz , rather a old Issue that mudlord fixed on my fork like a 3/4 year ago.
I just started pulling in some updates and saw that enableNoise is gone.

This may cause delays up to 20 seconds due to a lack of entropy without our fix under some circumstances.
Probably something you want to deal with upstream?
Reference replaces it with a simple xorshift (https://github.com/libretro/mupen64plus-libretro-nx/blob/develop/GLideN64/src/NoiseTexture.cpp#L38-L44) and there is virtually no visual difference.
I'd be fine doing a PR too.

[mudlord]

Problem was:

There was TLS issues with MinGWs implementation of srand and rand(). They use thread local storage which can interfere with how libretro's port of mupen works, thanks to its usage of libco.

Not using anything that relies on threads fixes any stalls. This seems to give enough entropy.

[loganmc10]

Yeah I've never noticed any delay in upstream mupen64plus, or heard any complaints, and all the stuff I distribute for Windows uses MinGW

[gonetz]

Reference replaces it with a simple xorshift (https://github.com/libretro/mupen64plus-libretro-nx/blob/develop/GLideN64/src/NoiseTexture.cpp#L38-L44) and there is virtually no visual difference.

[gonetz]

I'd be fine doing a PR too.

Please do a PR.

[m4xw]

@gonetz Is it AL snippet tho?
If anything speaks against it I can implement it from scratch too.
Would you prefer a RNG class that takes in different types or just have it in NoiseTextures like we do for now?

[mudlord]

Yes it is. Any old RNG that doesnt use TLS, including prng would do, but AL's tiny code snippet works just as good, hence why it was used since its so small.

If it really is a problem: https://www.pcg-random.org/ use that.

[mudlord]

Yeah I've never noticed any delay in upstream mupen64plus, or heard any complaints, and all the stuff I distribute for Windows uses MinGW

Prob because it doesn't rely on cothreads or how libco does cothreads.

[gonetz]

If anything speaks against it I can implement it from scratch too.

No, I don't think that it is a problem. I just noticed a familiar code.

[m4xw]

@gonetz Would you prefer a RNG class that takes in different types or just have it in NoiseTextures like we do for now?
If you don't answer that I will just slap the commit 1:1 in a PR ;)

[gonetz]

I don't know what is RNG class. inline u32 irand() in NoiseTextures is fine for me.

[m4xw]

RNG* generator = new RNG(RNG::CryptographicallySecure)
u32 number = generator->randomU32();
delete generator;
generator = new RNG(RNG::XorShift);
number = generator->randomU32();
delete generator;

Could look something like this and we can refactor it in GLideN64.
Could also do it as a singleton.
(If it isn't obvious: I would write it for GLideN64)

[gonetz]

RNG class is ok. It should be lightweight, so singleton is not necessary.

[gonetz]

@m4xw Please do a PR.

[m4xw]

@gonetz I plan to do so after I got my mupen next release wrapped up, its currently stalling since a month because we are investigating a nasty issue in new_dynarec and I also currently work on a Citra port to Switch.
Sorry I didn't forget it, I just have my hands full :/

[gonetz]

Sorry I didn't forget it, I just have my hands full :/

It's ok, nothing urgent here.