Question about porting shaders to zig

Help
1

Hello, i am attempting to move my shader code from Slang to Zig.
however i am unsure of two things, first, how do i compile shaders at runtime?

for slang, i have a library that converts Slang code into SPIRV, but i am unsure as to how to do that with zig, wouldn’t that entail shipping the zig compiler as well?

there’s also the gpu structs issue, where you need structs on both the CPU and shader side, how would i handle doing that without defining them twice?

(i use master version of zig for the latest SPIRV changes.)

for example, this PushConstants struct must be the same across CPU and GPU
if runtime compiling is possible, how would i be able to assert that this struct is not changed in shape?

pub const PushConstants = extern struct {
    pub const max_push_constants_size = 128;
    comptime {
        if (@sizeOf(PushConstants) > max_push_constants_size)
            @compileError("size of push constants can't be more than 128 bytes");
    }
    /// could be a BDA pointer, could be an index into an array. determined by the shader.
    arbitrary_data_1: u64 = 0,
    /// could be a BDA pointer, could be an index into an array. determined by the shader.
    arbitrary_data_2: u64 = 0,
};
1 Like
2

Here are a few projects using zig shaders

None of these projects compile the shaders at runtime though. Can I ask what your usecase is?

For the 2nd question, here’s what I do:

comptime {
    if (builtin.target.cpu.arch.isSpirV()) {
        @export(&vertex, .{ .name = "vertex" });
        @export(&fragment, .{ .name = "fragment" });
    }
}

I have this block so that other files can import shader.zig without re-exporting the entry points (if you were doing export fn main() ...). And then everything else is normal importing wise. Make sure to put arrays instead of vectors in your structs because @Vector has a well defined layout on spirv but not on other targets.

3

my project is a game one, and i intend to have the shaders be modifiable as part of my game modding efforts. Just the logic inside the stage main functions though.
however it is a minor thing, and i’m fine dropping it if it means i don’t have to duplicate code.

4

Ah that makes sense. I don’t know what I’m talking about but presumably you’d want to accept SPIR-V directly rather than compile it yourself, or at least compile glsl or some other shader language right? Unless by modifying shaders you mean literally modifying the existing shader’s source code then I would guess that an established shader language would be more accessible to end users. Maybe this is useful Linkage SPIR-V specification?

5

Oh no, my project already does runtime shader compilation, its just that im using another language for shading when i’d rather have everything in zig.

it seems it might not be easily possible to compile zig shaders at runtime, so i’ll just keep it at compile time for now. thanks for the links!

1 Like
6

Actually, is it possible to import a source file from both sides, CPU and spirv ?
by file, i mean source files within your project, not an external package.

i tried doing that, and it spat an error, something something, module can have only one owner at a time, to that effect.

7

Yes, but your module structure sounds like it’s wrong. If you want to share a file between two modules, it will have to be a third module imported by both.

In order to compile shaders from Zig at runtime, you’d need to run the zig compiler at runtime. That’s clearly possible but might be more of a headache than compiling GLSL… Since SPIR-V is an intermediate representation, I wonder if it’s possible to ship that?

2 Likes