Show HN: A SIMD-accelerated noise library in Rust | Hacker News Reader

Show HN: A SIMD-accelerated noise library in Rust

github.com

73 pointsgameswithgo23 comments

> Sometimes you may want to use SSE41 even with AVX2 is available.

I'm glad this is an option. I feel like a lot of libraries assume you always want the widest SIMD width possible, when this is very likely to cause performance issues for many cases.

exactly!

Very nice! Any plans to extend it to support more noise types and 1D and 4D variants? This may serve for inspiration: https://github.com/Auburns/FastNoiseSIMD

OT but I keep reading "fart noise"

The author of that is a good friend! I was showing him my SIMD C++ noise library and that inspired him to make that (which is much much better than the thing I had hacked together in c++)

Doing SIMD accelerated 1D noise is probably pointless, as it will be so fast. I could add scalar versions of 1d though.

I'm up for 4D potentially if anyone has some use cases.

4D ist commonly utilized for any 3D use case that needs to vary over time. Likewise, 3D noise is also used for 2D that needs to vary over time.

Yeah I understand that being the stated reason I've just not seen it actually done very often as the performance/memory use is an issue. I've been surveying some people though and a couple people are actually using it, looks like!

Another interesting usecase is generating seamlessly tiling noise [1]. Admittedly this is usually done in advance where slower performance is fine, but fully or mostly procedural games could really benefit from it. Combining this with prime number-sized layered textures [2] gets you a very organic looking texture with only an upfront rendering cost, making it plausible to generate high resolution unique textures for everything in a game on the fly.

[1] https://gamedev.stackexchange.com/a/23639 [2] https://news.ycombinator.com/item?id=2419347

Any reason to stick with the horrible intel intrinsic C API ?

TBH I find assembly kernels generally more readable as long as one keep a few comments in there to explicit register allocation.

I mean, if you are being serious, there are tons of reasons to use the C API. I heavily use intrinsics in C++ templates. Clever use of templates allows me to write a function once which can compile to SSE/AVX/AVX-512 and different data types (float/double) and different arch (x86/x64). In most situations this will be faster than assembly since I can inline everything wherever I want. When the need arises I will drop down to assembly to try to get any last perf gains, but otherwise I found that clang/icc/msvc are pretty good at generating assembly.

I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly.

I absolutely agree that once wrapped up there are good reasons to use a language-level interface instead of asm for most things.

As I get more familiar with rust macros I may compress this down a bunch. It will make it easier to maintain.

As another example, this morning I needed to perform a small convolution in an inner loop. Since I'm targeting x64 under the msvc compiler I can't write an external assembly function and have it inlined into the inner loop. Therefore I was left with just using the raw intrinsics from intrin.h for like, 10 lines of code. The simplicity of the convolution means the compiler will have no problems generating optimal code.

For me the ugliness of the intrinsics has gone away, like parens do for a lisp programmer.

> I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly.

The compiler is aware of many of those intrinsics and can perform optimizations around them. Hand rolling all of that in Assembly would be quite the chore. Using these intrinsics is, IMO, considerably easier.

Rust chose to adopt the vendors' naming schemes exactly as they were defined, instead of inventing their own. The idea was that these intrinsics are official, well-understood and people will build higher-level abstractions on top of them anyway.

To elaborate a bit, the intention is to first stabilize the platform-dependent low-level intrinsics just as specified by each vendor, under the "arch" namespace in the standard library (e.g. `use std::arch::x86_64::whatever`, which is quite self-explanatorily nonportable). This will hit stable Rust as of the next release, on June 21. Future work will focus on building a more portable, more Rust-like, higher-level API on top of these intrinsics under the "simd" namespace in the standard library; you can see the current state of this work at https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/s... .

What common use cases does this have? Not sure when I’d ever use it.

Generating procedural textures in 3D graphics, such as marble. Generating random texture things like topology heighmaps for maps in games.

Those are the only two times I have bumped into this kind of noise but I'm sure there are a few more uses.

Generating textures and geometry in games and art tools are the most common applications.

Some examples:

http://libnoise.sourceforge.net/examples/complexplanet/index...

Wow! Cool examples. Thanks!

That's not what 'noise' looks like to me, or well, it's not the white noise I'd associate with TV, more like err, a semirandom generated height map of sorts. Still, that amount of detail requires billions of datapoints, generating those quickly is beneficial. I can imagine games like Elite: Dangerous and No Man's Sky use those a lot for the trillions of planets they have.

These are all examples of "Gradient Noise" which is intended to produce naturally varying types of noise.

There is also value noise, white noise (what you are thinking of), cellular noise. It is an interesting field!

value noise and white noise are computationally easy enough that it probably doesn't make sense to simdify them. probably!

Reply on news.ycombinator.com