OT: I just spend a few minutes searching for the source of the "Not all CPU operations are created equal" slide of the linked presentation (Andrew Kelley - Practical DOD), its here:
The GPU loves arrays of structures AoS, since all vertex data fits in its triangle assembly cache. Once given to the GPU, the software side doesnt really care for all vertex parameters so this optimisation is pointless. Only relavent when you have instance rendering (leaves, grass) but then you only need an array of vec3’s, not the other parameters so back to normal arrays.
Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.
Blind leading the blind. Disclaimer - I do professional rendering engines.
Splitting fat vertex component data into multiple streams also often makes sense in rendering engines (e.g. not all vertex shaders might need all vertex components). Strict SoA or strict AoS hardly ever makes sense, but an 'inbetween' approach often does (maybe call it SoAoS) - and this should be possible just fine with Zig's comptime approach, e.g. only apply the SoA transform to the toplevel items of a struct.
As for CPU-side vector math:
Zig already has a @Vector type (which will probably be renamed to @Simd) and it will get a builtin matrix type. With those two things, the main reason for operator overloading in game/rendering engines is pretty much handled via builtin types.
10 comments
[ 4.0 ms ] story [ 35.5 ms ] threadhttps://6it.dev/blog/infographics-operation-costs-in-cpu-clo...
Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.
Blind leading the blind. Disclaimer - I do professional rendering engines.
As for CPU-side vector math:
Zig already has a @Vector type (which will probably be renamed to @Simd) and it will get a builtin matrix type. With those two things, the main reason for operator overloading in game/rendering engines is pretty much handled via builtin types.