# Zig is getting support for vec2, vec3, vec4 types to the language **URL:** \ **Category:** News\ **Tags:** language\ **Created:** [April 22, 2026, 8:27pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124 "2026-04-22T20:27:22Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\ **Post date:** [April 22, 2026, 8:27pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/1 "2026-04-22T20:27:22Z")
Just wanted to share this đŸ€©[add vec2, vec3, vec4 types to the language #32032](https://codeberg.org/ziglang/zig/issues/32032#issue-4516628) ---
**Author:** ![wbrian](https://ziggit.dev/user_avatar/ziggit.dev/wbrian/32/4227_2.png) [@wbrian](https://ziggit.dev/u/wbrian)\ **Post date:** [April 22, 2026, 8:41pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/2 "2026-04-22T20:41:02Z")
Marked “urgent” even. I wonder why? ---
**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\ **Post date:** [April 22, 2026, 8:43pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/3 "2026-04-22T20:43:53Z")
Yeah can’t wait to see how this will pan out 🙂 ---
**Author:** ![asibahi](https://ziggit.dev/user_avatar/ziggit.dev/asibahi/32/5416_2.png) [@asibahi](https://ziggit.dev/u/asibahi)\ **Post date:** [April 22, 2026, 8:44pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/4 "2026-04-22T20:44:22Z")
Urgent just means triage ---
**Author:** ![Kaeru](https://ziggit.dev/user_avatar/ziggit.dev/kaeru/32/3335_2.png) [@Kaeru](https://ziggit.dev/u/Kaeru)\ **Post date:** [April 22, 2026, 8:55pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/5 "2026-04-22T20:55:39Z")
Would any graphics programmer be willing to go more into detail about what SPIR-V backend + glsl means within the Zig ecosystem. I understand one is an Intermediate Representation and I understand the second is a shader language (?) Does zig want to allow shader code to be run on GPUs to be entirely written in Zig? ---
**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\ **Post date:** [April 22, 2026, 8:58pm UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/6 "2026-04-22T20:58:25Z")
not a graphics programmer, but I’m pretty sure this is one of zig’s ambition, to be usable as a shading language at least there’s an `ofmt=spirv` option when emiting code. ---
**Author:** ![Lowell](https://ziggit.dev/user_avatar/ziggit.dev/lowell/32/7145_2.png) [@Lowell](https://ziggit.dev/u/Lowell)\ **Post date:** [April 23, 2026, 3:18am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/7 "2026-04-23T03:18:48Z")
Targeting SPIR-V would allow (at least a sizable subset of) the same Zig code to be run reasonably parallel on a CPU, or massively parallel on a GPU or NPU. This would make Zig’s strength in cross-compilation really useful for use cases like simulation, offline graphics, UI rendering, and anything else where you’d normally have to duplicate work just to have it both on the CPU and GPU (communicating data between the two can be expensive and troublesome, and sometimes you want the CPU as a fallback when a GPU isn’t available or suitable). It also just makes shader code more approachable for people not specialized in graphics programming. Breakpoints / debuggers are platform and vendor-specific (and necessarily different from CPU debuggers), and print statements are essentially unavailable in GPU programming. ---
**Author:** ![Luke](https://ziggit.dev/letter_avatar_proxy/v4/letter/l/7ab992/32.png) [@Luke](https://ziggit.dev/u/Luke)\ **Post date:** [April 23, 2026, 6:48am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/8 "2026-04-23T06:48:45Z")
Pardon my ignorance but does it mean zig wants to do what cuda does? ---
**Author:** ![WeeBull](https://ziggit.dev/user_avatar/ziggit.dev/weebull/32/6828_2.png) [@WeeBull](https://ziggit.dev/u/WeeBull)\ **Post date:** [April 23, 2026, 9:06am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/9 "2026-04-23T09:06:23Z")
This feels like Zig would be getting multiple features doing extremely similar things without a clear distinction between them. The ticket talks about how `@Vector` is for SIMD, but `vec2/3/4` also describes a number of SIMD operations. It also talks about `vec` types supporting swizzles, but CPU SIMD often has “permutation” instructions which are swizzles so `@Vector` would probably benefit from a way to describe those. Now `i16` is equivalent to `@Int(signed, 16)`, so maybe `vec4` is equivalent to `@Vector(4, f32)` as a shorthand. That makes sense to me, but a whole new type doesn’t. ---
**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\ **Post date:** [April 23, 2026, 9:20am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/10 "2026-04-23T09:20:54Z")
it is an accepted proposal to rename `@Vector` to `@Simd` which should help. But the line is pretty clear once you know what the types are. `@Simd` is an **optimisation** primitive for when the compiler doesn’t do a good enough job for you. Meaning that when you use it the compiler trusts that you know better, even if it is clearly suboptimal. As is usually the case if you try to use it in place of mathematical vectors. The proposed `vec` types will be mathematical vectors intended specifically for shaders/game dev. They have very different use cases, if you find the terminology confusing that is the fault of SIMD using maths language inaccurately. Though it is at least better than using “vector” to describe a dynamic, and generic, array as c++/rust/etc have done. ---
**Author:** ![floooh](https://ziggit.dev/user_avatar/ziggit.dev/floooh/32/2989_2.png) [@floooh](https://ziggit.dev/u/floooh)\ **Post date:** [April 23, 2026, 9:47am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/11 "2026-04-23T09:47:39Z")
> The proposed `vec` types will be mathematical vectors intended specifically for shaders/game dev. Tbh the distinction isn’t clear to me either. I also never understood where the ‘mathematical vector’ angle is coming from, since game-dev/shading-language vectors _are_ SIMD-style vectors - all operators on vec2..4 are component-wise (most notably multiplication is `{ .x=a.x*b.x, .y=a.y*b.y, .z=a.z*b.z, .w=a.w*b.w }`, and special ‘algebraic’ products like cross- or dot-product are implemented as builtin functions in shading languages (in old-school C++ vector libraries the `*` and `%` operators were sometimes overridden to mean either cross- or dot-product, but I don’t think that’s still en vogue and I would advice Zig to not go down that road, instead have a `@dot(x, y)` and `@cross(x, y)` builtin, and/or stdlib funcs). ---
**Author:** ![Cloudef](https://ziggit.dev/user_avatar/ziggit.dev/cloudef/32/1370_2.png) [@Cloudef](https://ziggit.dev/u/Cloudef)\ **Post date:** [April 23, 2026, 9:59am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/12 "2026-04-23T09:59:14Z")
Dot product for single inputs don’t really simdify well. The idea of simd is always to work in batches. For example good simd dot product would look something like (which gives you 3 different dot products!): ```zig pub fn dot_batch(x1: @Vector(3, f32), y1: @Vector(3, f32), z1: @Vector(3, f32), x2: @Vector(3, f32), y2: @Vector(3, f32), z2: @Vector(3, f32)) @Vector(3, f32) { const x = x1 * x2; const y = y1 * y2; const z = z1 * z2; return x + y + z; } ``` ---
**Author:** ![pzittlau](https://ziggit.dev/letter_avatar_proxy/v4/letter/p/ecae2f/32.png) [@pzittlau](https://ziggit.dev/u/pzittlau)\ **Post date:** [April 23, 2026, 10:00am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/13 "2026-04-23T10:00:42Z")
I’m also always perplexed by the mathematical vector distinction. It’s just some “list of numbers” and the easiest way to lay them out is just everything one by one, a SIMD-style. As for multiplication I would go even so far and just disallow the `*` operator completely because it isn’t well defined. There at least 4 vector products I can think of on the top of my head that are used reasonably often: `dot`, `cross`, `hadamard/component`, and `outer`. Having the `*` as a shortcut for one of those just leads to confusion because the one you want the shortcut for very much depends on context. If we go further to matrices it’s pretty similar. There are a bunch of products mathematicians came up with. But _in contrast to vectors_ when one talks about a matrix product it’s always the same, while things like the hadamard product here are way more niche. ---
**Author:** ![floooh](https://ziggit.dev/user_avatar/ziggit.dev/floooh/32/2989_2.png) [@floooh](https://ziggit.dev/u/floooh)\ **Post date:** [April 23, 2026, 10:03am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/14 "2026-04-23T10:03:44Z")
The batching is a good point, but that works just as well with GLSL-style vec2..vec4, the input data just needs to be provided differently (basically “pre-swizzled”), e.g. I do this sort of ‘4-batching’ in this GLSL shader for GPU skinning (note the `xxxx`, `yyyy`, `zzzz` vecs, this is basically doing a ‘manual’ matrix multiplication via 3 dot products). > ---
**Author:** ![Cloudef](https://ziggit.dev/user_avatar/ziggit.dev/cloudef/32/1370_2.png) [@Cloudef](https://ziggit.dev/u/Cloudef)\ **Post date:** [April 23, 2026, 10:13am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/15 "2026-04-23T10:13:21Z")
My point is that if you use SIMD vector to calculate single dot product, you end up with worse code than doing it with scalars. Linear algebra vectors wouldn’t have to force SIMD code generation so it could decide more what kind of code to generate I guess. ---
**Author:** ![AndrewKraevskii](https://ziggit.dev/user_avatar/ziggit.dev/andrewkraevskii/32/2564_2.png) [@AndrewKraevskii](https://ziggit.dev/u/AndrewKraevskii)\ **Post date:** [April 23, 2026, 10:34am UTC](https://ziggit.dev/t/zig-is-getting-support-for-vec2-vec3-vec4-types-to-the-language/15124/16 "2026-04-23T10:34:41Z")
Here is writeup about state of zig gpu backend [Zig and GPUs](https://alichraghi.github.io/blog/zig-gpu/).