Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IMHO Slang fixes two problems in one tool:

- the frontend language is mostly compatible with HLSL, which is the defacto shader authoring standard in the gamedev industry

- it compiles to the 'shader language/bytecode zoo' of the different 3D APIs (since recently even WGSL/WebGPU)

So it lets you author your shaders in a single language that's already accepted by most of the industry, and target the various 3D APIs (D3D, Metal, GL, WebGPU, ...).

It is already possible to build such a tool yourself by glueing together existing libraries (like glslang, SPIRVTools, SPIRVCross and Tint), but it requires quite some work and there are little annoying details like SPIRVCross never supporting WGSL output for some non-technical reasons (so that you need a separate library like Tint just for the SPIRV-to-WGSL conversion). In fact there are tons of such engine-specific shader cross-compilers, all built around the same few Khronos libraries and doing more or less the same thing. Slang looks like it could be the standard replacement for all those custom solutions.

For my own needs, the main thing I'll need to investigate is how easy it is to add engine-specific custom annotations to Slang resources and then output those as part of the reflection information.



In my very limited experience: In addition to cross-compiling, you want additional features that WGSL doesn't provide if you want to compose shaders, so you'd end up with a tool like naga-oil [1] or wesl anyways.

[1] https://github.com/bevyengine/naga_oil


Thanks. Yes I do tend to overlook HLSL, despite being a windows user and a game developer, I tend to focus on gfx technologies that come out of Khronos and the W3C. Slang does look a lot like GLSL, I am trying to get used to WGSL at the moment and it's slow going.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: