Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig – SPIR-V Backend Progress

ziglang.org

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Zig – SPIR-V Backend Progress

#41

Post by _bohm »

laszlojamf wrote: post #3

I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach…

I’m writing a game engine in Zig and after tens of thousands of lines written, I have to say my mind has totally melded to the language. It really hits a sweet spot for me between being expressive enough, and there only being one way to do something most of the time.

Re: Zig – SPIR-V Backend Progress

#44

Post by Zambyte »

laszlojamf wrote: post #3

I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach…

> To an untrained eye, it seems like go, but with manual allocation.

I've written a decent amount of Zig, Go, and C, and I often describe Zig as in between Go and C. So your untrained eye seems pretty accurate. Maybe it's just not the tool you need, and that's fine! I could get excited about a new tractor that is well built and leans heavily into right to repair activism, but I live in a city and wouldn't use it.

Re: Zig – SPIR-V Backend Progress

#45

Post by flohofwoe »

mccoyb wrote: post #31

This is inspiring! At the same time, it’s not exactly clear to me how this is going to work in the long term without changes to the Zig language itself, questions below. Assuming the goal is to be able to write compute kernels and shaders in Zig - the concerns of writing (and especially optimizing) these programs are significantly different from high-performance CPU execution. Mojo, for instance, has seemed to solve…

Zig's SPIRV support is on the same abstraction level as GPU shading languages (GLSL, MSL, HLSL, WGSL, ...), there's nothing particularly "magic" about turning imperative source code (no matter if Zig or any other language) into a sequence of SPIRV instructions, it's not all that much different from generating x86 or ARM instructions.

The main difference to 'traditional' CPU programming is that you don't write an entire 'application' with a single main function, but instead many small-ish self-contained functions that will run 'per vertex', 'per pixel' or 'per compute invocation' on the GPU.

The Zig toolchain is only concerned about how to compile Zig code into SPIRV blobs, but not about how that code is then 'uploaded' and 'orchestrated' on the GPU, instead this is the job of APIs like Vulkan (e.g. there is no magic integration between CPU- and GPU-side code in the Zig toolchain like in the CUDA toolchain).

SPIRV's specification basically defines what features Zig needs to expose as specialized builtins or language features (e.g. things like `@SpirvType(.sampler);` or `@SpirvType(.{ .image = .{...` or `@extern(*addrspace(.constant)` map directly to SPIRV concepts (the same concepts that dedicated shading languages had to add on top of C or C++).

Re: Zig – SPIR-V Backend Progress

#48

Post by mccoyb »

flohofwoe wrote: post #45
mccoyb wrote: post #31

This is inspiring! At the same time, it’s not exactly clear to me how this is going to work in the long term without changes to the Zig language itself, questions below. Assuming the goal is to be able to write compute kernels and shaders in Zig - the concerns of writing (and especially optimizing) these programs are significantly different from high-performance CPU execution. Mojo, for instance, has seemed to solve…

Zig's SPIRV support is on the same abstraction level as GPU shading languages (GLSL, MSL, HLSL, WGSL, ...), there's nothing particularly "magic" about turning imperative source code (no matter if Zig or any other language) into a sequence of SPIRV instructions, it's not all that much different from generating x86 or ARM instructions. The main difference to 'traditional' CPU programming is that you don't write an enti…

Thanks: very helpful and clear.

Re: Zig – SPIR-V Backend Progress

#49

Post by jsrcout »

dnautics wrote: post #12
weitzj wrote: post #10

Side question as I am following zig only losely and do Go Programming: Zig has the feature that you can drop in your allocator from the caller. Now with 0.16 you also "bring your own IO" implementation with you. And for my understanding this looks like the pattern Go uses with its Context package, where you pass in transitive data, cancellation signals and timers to for example stop an SQL query in server B, since a…

not really sure what you're asking. but time is now part of the io interface, so you can pretty easily write your own io implementation that just stubs out to the stdlib's default io content and has custom time functions if you want to try something funky. This is pretty close to what you are asking for (and in terms of functionality, equivalent). I say go for it and see what happens, report back!

> time is now part of the io interface [...]

Nice, didn't know that! Sounds like this could be extremely useful for some of the simulators we work on (though we mostly work in C/C++).

Post reply on HN