シェーダ開発の最大の障壁が解決—@SpirvType の導入
Zig言語チームは2026年6月、SPIR-V（Vulkan や OpenCL などの GPU コンピュート環境で使用される中間言語）バックエンドの現代化に取り組みました。Ali Cheraghi 氏による報告によると、SPIR-V バックエンドは最近のコンパイラ変更に対応できていなかったため、数週間かけて抜本的な改修が行われたとのこと（出典）。
新しい @SpirvType ビルトインが導入されたことで、長年の課題だったシェーダ開発がようやく実用的になってきました。
これまで Zig の型システムでは表現できなかった GPU 固有の型（Sampler、Image、SampledImage、RuntimeArray など）が、新しい @SpirvType ビルトインにより直接利用可能になりました。これは非常に重要な改善です。従来は、こうした型を使いたい場合、インラインアセンブリや複雑な回り道をする必要がありました。
開発者が GPU シェーダを書く場合、以下のような記述が可能になります。
const Sampler = @SpirvType(.sampler);
const Image = @SpirvType(.{ .image = .{
.usage = .{ .sampled = u32 },
.format = .unknown,
.dim = .@"2d",
.depth = .unknown,
.arrayed = false,
.multisampled = false,
.access = .unknown,
} });
このレベルの親切さが整っていれば、C や C++ で書く場合と同等かそれ以上の開発体験が実現できるだろうと感じます。
呼び出し規約への Execution Mode 統合—コンパイラの仕事をシンプルに
もう一つの大きな変更は、GPU の実行モード（ワークグループサイズ、フラグメント原点座標の解釈方法など）の扱い方です。従来は inline assembly を使って手動で OpExecutionMode 命令を発行する必要がありました。
今回のアップデートでは、これらの実行モード情報が呼び出し規約（calling convention）に統合されました（出典）。
| 要素 | 従来の方式 | 新方式 |
|---|---|---|
| 実行モード指定 | inline assembly + OpExecutionMode | callconv パラメータ |
| ワークグループサイズ | 手動記述 | callconv に統合 |
| フラグメント情報 | ad hoc に発行 | calling convention で管理 |
| メッシュシェーディング | 対応なし | spirv_task、spirv_mesh 新規追加 |
新しい callconv の使用例は以下の通りです。
export fn vert() callconv(.spirv_vertex) void {}
export fn comp() callconv(.{ .spirv_kernel = .{ .x = 8, .y = 8, .z = 1 } }) void {}
export fn mesh() callconv(.{ .spirv_mesh = .{ .stage_output = .output_lines, .max_primitives = 1, .max_vertices = 2 } }) void {}
実行モードをコンパイラが型安全に管理できるようになったことで、シェーダバグが劇的に減ると予想します。
このアプローチにより、プログラマが不正な値を誤って設定する可能性が低くなります。inline assembly という「逃げ道」を塞ぐことで、型チェック時にエラーを検出できるようになったわけです。正直、システムプログラミング言語として Zig がやるべき仕事はこういうところにあると感じます。
コンパイラのスレッド化とモジュール链结—本格的なプロダクション対応へ
Zig の他のバックエンド（x86-64、ARM など）と同じように、SPIR-V バックエンドもマルチスレッド化されました。これまでは SPIR-V コード生成がリンカスレッド内で単一スレッドで実行されていたため、複数ファイルのコンパイルが遅かったと予想されます。
今回の改修では、各コード生成ジョブが Mir（中間表現）値を生成し、コンパイラのスレッドプール上でスケジュールされるようになりました。これに伴って、以前削除されていた 2 つの最適化パス（dedup_types と prune_unused）も復活しました（出典）。
加えて、.spv ファイルがオブジェクトファイルとして認識されるようになりました。つまり、複数の .zig ファイルと外部の .spv オブジェクトファイルを混在させて、SPIR-V リンカで 1 つのモジュールにまとめることができるようになったということです。
これらの改善により、現在の spirv64-vulkan ターゲットでのテスト成功率は 49% に達しており、1 ヶ月前と比べて約 10% 向上しているとのこと。自分の印象としては、シェーダプログラミングに Zig を使う選択肢がいよいよ現実的になってきた段階だと感じます。
開発者向けの実用的な判断基準
Zig でシェーダやコンピュートカーネルを書きたい開発者にとって、このタイミングは「試す価値がある時期」です。ただし以下の点に留意してください。
- テスト成功率が 49% という水準：まだ本番環境への導入には早い段階です
- バグ報告は大歓迎：プロジェクトが積極的にフィードバックを求めている状況
- WebGPU や DXC（DirectX Shader Compiler）との互換性については言及なし：これらとの関係は今後の展開次第
もし個人プロジェクトや実験的な用途で GPU コンピュートに取り組む予定があるなら、Zig を試してみる価値は十分あります。システムプログラミング言語として C や C++ より安全な記述ができますし、SPIR-V 対応により Vulkan や OpenCL に直接アクセスできる利点は見逃せません。
