ISPC vs your SIMD implementation

[iperov]

Have you considered using ISPC ?

[Dawoodoz]

Because software rendering is very sensitive to any failure to vectorize control flow, I plan to create a simpler shader language similar to Halide. Then I can integrate it directly with the image types for easy use, create templates for different ways of iterating over the image, integrate vertex shaders with the 3D rendering pipeline, and build on top of the existing hardware abstraction layer in simd.h so that the compiler becomes more timeless and requires less maintenance.
#80

This should hopefully make the framework more accessible to junior developers who are not used to low level programming but want the robustness of software rendering. With a more powerful general purpose language such as ISPC, a beginner is more likely to accidentally write code that can not be vectorized due to procedural control flow, similar to the auto vectorization features that already exist in C++ compilers. Functional language features can instead guarantee that the code will be translated into operations on portable SIMD vectors, which will be vectorized when available in the target hardware.

[iperov]

With a more powerful general purpose language such as ISPC, a beginner is more likely to accidentally write code that can not be vectorized due to procedural control flow

actually disagree, because on ISPC you write one algorithm for each SIMD's lane , which eliminates “falling” into unoptimized code.

upd

almost like GLSL, but with some modifications

[iperov]

there's more of a question here about the survivability of code over generations according to your philosophy. It is unknown whether ISPC will be supported further or something else will be invented in its place.

[iperov]

I plan to create a simpler shader language similar to Halide

by the way on ISPC you write shader-like code by default

for example

export void circle_faded(uniform float img[], uniform uint32 W, uniform uint32 H, uniform float cx, uniform float cy, uniform float fs, uniform float fe)
{
    uniform float d = max(fs, fe) - fs;
    if (d == 0.0f) 
        d = 1.0f;
    
    uniform vec2 c = vec2(cx, cy);
    foreach(y = 0 ... H, x = 0 ... W)
    { 
        vec2 pt = vec2(x, y);
        float dist = length(pt - c);
        img[ IDX2D(H,W,y,x) ] = min(1.0f, max(0.0f, 1.0f - (dist - fs) / d));
    }
}

and this is compiled to highly optimized sse/avx code to .o and .h files ready to link

also with clang

-nodefaultlibs -nostdinc -nostdinc++
-g0 -flto=thin -O3 -fno-unwind-tables -fno-exceptions -fno-pch-codegen -fno-pch-debuginfo -Wl,--strip-debug

you build shared lib in miliseconds, like in opengl shader compile, and load in your program and use at runtime

[iperov]

by the way
Isn't it logical that the GPU approach will outlive SIMD ?
In GPU you only program 1 thread per pixel easily.
I'm not familiar with Hardware but I think it's easier to build tens of thousands of cores on GPU than SIMD instructions in a complex CPU.

also, at the moment, even old GTX750 has more flops than high-end AMD Ryzen7

[Dawoodoz]

In assembler for graphics cards, SIMD is used to process RGBA or XYZW in the same instructions using 4 lane SIMD for channels. CPU, GPU, DSP, FPGA, everything except microcontrollers use SIMD today, because it is the easiest and most cost effective way to increase performance when designing hardware pipelines. In language design, it is good to hide the manual work with SIMD, but under the hood, SIMD will probably survive the CPU itself.

If SIMD goes missing in the future, it will be because computers are so fast that optimizations are no longer needed. In that case, simd.h will automatically fall back on scalar operations.

[iperov]

@Dawoodoz Have you tested template-only code without simd for performance using a clang compiler where superior automatic vectorization is present?
https://llvm.org/docs/Vectorizers.html

[Dawoodoz]

No matter how good the compiler is, auto vectorization is an almost impossible task, because there is a lot of missing communication both ways. Developing with auto vectorization feels like carefully building a house of cards, only to have it all collapse into nothing without knowing why a tiny change made the code mathematically impossible to vectorize. There are alignment and ownership assumptions about pointers needed to overwrite padding at the end. Using int instead of uint8_t can prevent tight packing in 8-bit vectors. If you switch compiler, you have to start over again trying to follow those rules without breaking the rules of the previous compiler. To be both fast and future proof, you need code that is independent of specific compilers and optimized using a hardware abstraction layer or code generator.

[iperov]

But writing intrinsics under simd is also such a thing. Ideally you just write math code and it's quite acceptably optimizable.
Isn't it?
Wouldn't that give more freedom, ease, and confidence in the survivability of the code?

By the way, if sprites are just pre-rendered into textures, does the speed of their rendering matter? We can just allocate some amount of flops per frame, and spend it on rendering. The object will just appear later in the game, but for before it will be a silhouette instead.

[Dawoodoz]

With simd.h, you just replace the scalar type with a portable vector and iterate in strides, so most of the code is identical to a scalar loop.

[iperov]

ok, why not to use libs like https://github.com/p12tic/libsimdpp ?

[Dawoodoz]

libsimdpp is the same thing as what already exists in simd.h.