WebGPU’s Rust implementation, wgpu, uses Naga to translate WGSL into backend shading languages.
This is not quite the right way to phrase this. WebGPU is a W3C standard, and it has at least three implementations that I'm aware of:
-
Google's Dawn
-
wgpu, an open-source project to which Mozilla heavily contributes, but which we do not control (in classic open-source style)
-
WebKit's WebGPU implementation, which I don't think has its own name, written by Apple.
That is, wgpu happens to implement WebGPU, but it doesn't "belong to" WebGPU, as the proposal's phrasing suggests.
So it would be more accurate to say:
Firefox's implementation of the WebGPU W3C standard uses Naga, a Rust crate, to translate WGSL into backend shading languages.
The proposal then says:
This ignores Naga’s own optimizations because DXIL is a subset of LLVM IR and already structurally close to Naga’s IR, emitting DXIL directly is both feasible and attractive.
I don't think "Naga's own optimizations" is what you mean here. When we were talking, I think I didn't explain this clearly.
Although Naga certainly transforms programs from source to IR, and then back to source, it avoids performing optimizations, as such. Once wgpu hands Naga's output to Direct3D, Direct3D will apply an optimizing compiler to it anyway, before generating GPU machine code. So there's no need for Naga to spend the time and complexity to optimize the code as well. Naga's goal is merely to be accurate and fast (and ideally, produce somewhat legible output).
DXC could do optimizations. It includes a full copy of LLVM, after all. However, I think we pass it options to let it run as quickly as possible, again, because Direct3D will take care of optimization.
It turns out there's a DXIL spec! https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst I haven't read that spec, so I don't know how thorough it is. That documentation does say:
Prior to being converted into the low-level DXIL IR, a higher level IR is generated by codegen which is then transformed into DXIL by the optimizer. This lowers high-level constructs, such as user-defined types, multi-dimensional arrays, matrices, and vectors into simpler abstractions more suitable for fast JIT-ing in the driver compilers. DXIL is derived from LLVM IR.
I added the emphasis there. So I gather that one transformation DXC
must perform is scalarization: breaking down values of HLSL types
like float3 (a vector of three floats) into their individual
components (three separate float values). They say this work is done
"by the optimizer", but I wouldn't call this an optimization; it's
just lowering the program to a simpler form.
If your work produces DXIL directly from Naga IR, you will need to
perform this kind of scalarization as well: Naga IR has types like
TypeInner::Vector, and it seems that DXIL doesn't have anything like
a vector type.
Getting back to your text:
DXIL is a subset of LLVM IR
My understanding is that DXIL isn't exactly a subset of LLVM IR. It's more like, they snapshotted LLVM IR 3.7, and then made whatever changes to it that they felt like. Calling it a 'derivative' of LLVM IR would be more accurate.
You can check out the DXC sources here: https://github.com/microsoft/DirectXShaderCompiler It probably wouldn't be a bad idea to check out a copy of that source tree and see if you can get it to compile and run.
So perhaps that paragraph should say:
This is unnecessarily indirect. DXIL is a derivative of LLVM IR and already structurally close to Naga’s IR. The transformations that DXC must apply to the shader to generate DXIL are not complex. Thus emitting DXIL directly from Naga IR is both feasible and attractive.
From the proposal:
directly producing Naga to DXIL.
I would say:
directly producing DXIL from Naga IR.
From the proposal:
Naga. https://github.com/gfx-rs/naga. Accessed July 3,
That repository is retired; the current Naga sources are now in the wgpu Cargo workspace: https://github.com/gfx-rs/wgpu/tree/trunk/naga