exDM69

> But surely a generic tessellation approach could support perfect arbitrary transformations

Yes, but at typical font sizes this generates a lot of tiny triangles (0 to few pixels) which perfoms badly on GPUs.

> Slug doesn't seem to support any of these, it is just "for a given point, am I in or am I out?", but it doesn't tell you by how much

It does give you an anti-aliased value between 0 and 1 that estimates how much of a pixel is being covered.

But this is a linear estimate based on horizontal and vertical distance to the Bezier curve. It does not look correct at long distances, which is why you shouldn't use it for outlines, drop shadows or the other cool things you can do with (M)SDF. A single pixel outline works fine but is not really legible with modern display resolutions (very thin lines).

For finding the minimum distance between a quadratic Bezier curve and a point would require solving a 3rd degree polynomial, where Slug's algorithm gets away with solving a quadratic equation per pixel. This is makes a big performance difference.

> also think this is a deployment problem, not a build problem ...

This I agree with, deploying and running code for the correct cpu is a problem with no established solution.

As for actually writing the code, portable_simd is great. You need to adjust simd width and compiler config for the cpu you deploy to and fill in the blanks with intrinsics. Which is much less work per target than writing it all with raw intrinsics if you are deploying to more than one target.

> The second part of the problem is how you find the native vector length, so you can instantiate the generic function. IIRC this isn't even exposed in portable_simd and you have to use a seperate crate to get it.

This is trivial (but not pretty!) to do with something like `#[cfg(target_feature = "avx2")] const SIMD_WIDTH: usize = 8`. You need a few lines of ugly cfg logic to configure this.

A somewhat orthogonal and much more difficult problem is how to select it at runtime. You would either need to have different binaries built with different compiler options, link object files built with different compiler options to same binary, or dynamically link the correct code at runtime.

This is actually one of the (IMO only) cases where intrinsics are more practical: you can use `_mm256_add_ps` from AVX2 intrinsics regardless of whether you've configured your compiler to support AVX2 or not. As long as you check at runtime before calling the code so you don't get illegal instruction exceptions.

I can and I do use this is "actual code" and I've got benchmarks to prove that it's got better throughput (for the particular use case, don't extrapolate from there) and the same applies to AVX2 and AVX512: twice the native vector width has ~20% better throughput (ie. using `f32x32` on AVX-512).

I pass in the vector width as a generic parameter like this:

    fn do_simd_stuff<const N: usize>(x: Simd<f32, N>) { x.mul_add(x+x, x*x); }

With this I can easily benchmark the same code for any vector width. I can also do some compile time heuristics to choose the vector width based on what's available on the compile target CPU.

> you run out of registers and spill all over the place

As usual when optimizing SIMD code, you should keep an eye on the generated disassembly and the benchmark results and watch for register pressure and the other usual things.

I'm definitely NOT saying that you always get the best perf by using 2x SIMD width, but in this particular case it was so.

This is much much easier to do with portable_simd than if you'd write the same with intrinsics, you can change the SIMD width without having to rewrite all your code (e.g. changing from SSE `_mm_add_ps` to AVX `_mm256_add_ps` etc).

It's still a partial solution, you still need to drop down to intrinsics for some special instructions every now and then (which is easy), but in my projects this accounts for much less than 1% of the lines of code. Not applicable everywhere of course.

Counter question: why shouldn't it be portable?

It's definitely a 80% solution where you occasionally need to drop down to intrinsics (at zero runtime perf cost) for CPU specific instructions.

But just having vector types, arithmetic, swizzling, loads and stores will go a long way for basic tasks.

And with generics you can write code that is type and width agnostic. No need to rewrite your code of you want to go from SSE to AVX512, just change from f32x4 to f32x16 (or use generics) and you are done.

> They specifies a constant SIMD width so it's non-portable.

This is incorrect, you can use vectors wider than native SIMD width and the compiler will break them down to register size of the target cpu.

In fact it's sometimes better to used wider than native width, in some applications I see 20% better throughput with f32x16 (512 bits) on an AVX2 CPU (256 bits). It is kinda like loop unrolling it.

> misdirect Ukrainian drones toward NATO airspace (which has happened).

Claims to such effect has been made in public by reputable persons but they are not very credible nor has any supporting evidence been shown in public.

Drones getting lost due to GNSS jamming is happening.

But intentional misdirection towards a target would require GNSS spoofing capabilities over an impractically large area and that the drones would be susceptible to simple spoofing. They have satellite navigation, inertial navigation, terrain following cameras and listen to ground based radio sources like cell towers and are designed to operate in hostile RF environment. Just sending a fake GPS signal (several of them) won't make the drone divert to a specific target or direction.

I'm not buying the misdirection story until more compelling evidence is made public.

From what I have read (from unreliable sources), Ukrainian fighter pilots tried this a few years back and stopped due to too many losses.

To engage a slow flying drone with cannons from a fighter jet, they have to get really close while flying close to stall speed. They had some success in shooting down drones but the explosion and the debris caused several lost fighters.

Maybe something like a Embraer Super Tucano turboprop fighter with a gunpod could work. But that has very little other use in the battlefield.

> The best SIMD optimizations likely require changing your data format from AoS to SoA.

We do have gather load instructions in SIMD instruction sets these days (AVX2 and newer), so AoS vs SoA is not nearly as important as it was once.

Scatter stores are also available but only in newer CPUs.

> Is the `@reduce()` function in the example a special...

Yes, it is. In SIMD you can do a reduce for a commutative function in O(log N) steps. Sum, product, min, max, all, any, etc.

Although in this case it might be better if you just take the mask (vector of booleans), convert it to a bitmask and check if it is (non-) zero.

If the language provides it, you might also use .all() or .any() for a mask.

Thanks for listening to feedback. Seems like you've made many improvements since yesterday.

I played a few more rounds today. Fun!