3 ms·

I'm not entirely convinced spriv is good for webdev. imagine the only way to code in a browser was to use an offline compiler to emit byte code. some people mig

I'm not entirely convinced spriv is good for webdev. imagine the only way to code in a browser was to use an offline compiler to emit byte code. some people might like that but I'd argue there have been many indirect benefits to having the text version of JavaScript be the default on the web. sure there will be workarounds like building your own DSL to spriv compiler and including it on your page but I'd argue a standard high level text format leads to more collaboration / standardization / interop / knowledge sharing I'm sure others would prefer the web had just started as sandboxed assembly

shmerl 7y ago
SPIR-V already has a lot of collaboration, and will provide natural synergy with non Web use cases, since it's the standard bytecode format for shaders there already. So collaboration argument goes for SPIR-V here. Human readability of the shader shipped from the page is a different argument, and it can have some merit, but the same could be argued against using WebAssembly for instance which is not very human readable in comparison with JavaScript. I don't think it's a strong argument against using it.
Jasper_ 7y ago
I've had enough experience with deploying GLSL on many Android devices and also WebGL to be disillusioned with it. There's no great modern textual shading language out there, GLSL is missing a lot of modern niceities, HLSL isn't really an "independent language" (could talk more about that), and Apple's WHLSL/WSL proposal is drastically underspec'd to the point of hilarity. I think if you want to compile shaders from source, you are free to include your favorite transpiler as WebAssembly, like glslang. That's currently what I'm doing for my WebGPU prototype project.
- tomjakubowski 7y ago
  As someone who's only used GLSL of all the shader languages, what are some of the modern features it's missing?
  - Jasper_ 7y ago
    Generic types are probably one of the biggest ones. GLSL has generic builtins, but you can't define your own. But besides that, HLSL's support and management of buffers and bindings is a great deal saner than GLSL's. Especially the new syntax for loading structures from a ByteAddressBuffer. Beats the craziness that is SSBOs and image load/store. GLSL's upbringing with integrated texture/samplers is a bit ridiculous in a separable texture/sampler world, like in Vulkan. You need to create an integrated texture/sampler with the sampler2D constructor, and then immediately use it. The GLSL spec specifically says you can't pass it to your own user-created functions, I'm guessing because they didn't trust platform vendors to write working compilers? But glslang checks for it too, despite being the only GLSL compiler in the toolchain: https://github.com/KhronosGroup/glslang/blob/bd97b6f9f2132fa8df90431415e32dbab5c76db8/glslang/MachineIndependent/ParseHelper.cpp#L2367-L2385 https://github.com/KhronosGroup/glslang/blob/bd97b6f9f2132fa... You also can't put any binding object like texture2D in a struct, even though you can pass it between functions? The whole enterprise really feels like it was limitations in baby's-first-compiler that added a bunch of weird restrictions. HLSL is a C++-esque derivative that supports quite a bit more functionality than you probably imagine, and a lot less of the goofy limitations, given that it has a single compiler stack made by a company with competent compiler engineers.
TazeTSchnitzel 7y ago
SPIR-V “assembly” can be disassembled, the disassembly is fairly easy to read, and it's not that hard to write by hand, though rather verbose. An advantage of SPIR-V is that unlike both text-based programming languages and traditional machine code, SPIR-V is very very easy for machines to read and write — even for JS code — and it has a structure designed to be (mostly) cleanly extensible.
banachtarski 7y ago
As someone who has written in every shader dialect and also dealt with bytecode for all the major consoles, I think SPIR-V is really awesome tbh... The thing is, a text format is the worst format for interoperability between consoles, desktop and web. Having something like SPIR-V is more akin to LLVM for programming languages. LLVM doesn't preclude the existence of C, C++, etc, but it strictly benefits the ecosystem (which now includes Rust, Haskell, etc). In the same way, I see SPIR-V having the same potential as the interchange format for all the major IHVs.

shmerl 7y ago

SPIR-V already has a lot of collaboration, and will provide natural synergy with non Web use cases, since it's the standard bytecode format for shaders there already. So collaboration argument goes for SPIR-V here. Human readability of the shader shipped from the page is a different argument, and it can have some merit, but the same could be argued against using WebAssembly for instance which is not very human readable in comparison with JavaScript. I don't think it's a strong argument against using it.

Jasper_ 7y ago

I've had enough experience with deploying GLSL on many Android devices and also WebGL to be disillusioned with it. There's no great modern textual shading language out there, GLSL is missing a lot of modern niceities, HLSL isn't really an "independent language" (could talk more about that), and Apple's WHLSL/WSL proposal is drastically underspec'd to the point of hilarity. I think if you want to compile shaders from source, you are free to include your favorite transpiler as WebAssembly, like glslang. That's currently what I'm doing for my WebGPU prototype project.

tomjakubowski 7y ago
As someone who's only used GLSL of all the shader languages, what are some of the modern features it's missing?
- Jasper_ 7y ago
  Generic types are probably one of the biggest ones. GLSL has generic builtins, but you can't define your own. But besides that, HLSL's support and management of buffers and bindings is a great deal saner than GLSL's. Especially the new syntax for loading structures from a ByteAddressBuffer. Beats the craziness that is SSBOs and image load/store. GLSL's upbringing with integrated texture/samplers is a bit ridiculous in a separable texture/sampler world, like in Vulkan. You need to create an integrated texture/sampler with the sampler2D constructor, and then immediately use it. The GLSL spec specifically says you can't pass it to your own user-created functions, I'm guessing because they didn't trust platform vendors to write working compilers? But glslang checks for it too, despite being the only GLSL compiler in the toolchain: https://github.com/KhronosGroup/glslang/blob/bd97b6f9f2132fa8df90431415e32dbab5c76db8/glslang/MachineIndependent/ParseHelper.cpp#L2367-L2385 https://github.com/KhronosGroup/glslang/blob/bd97b6f9f2132fa... You also can't put any binding object like texture2D in a struct, even though you can pass it between functions? The whole enterprise really feels like it was limitations in baby's-first-compiler that added a bunch of weird restrictions. HLSL is a C++-esque derivative that supports quite a bit more functionality than you probably imagine, and a lot less of the goofy limitations, given that it has a single compiler stack made by a company with competent compiler engineers.

TazeTSchnitzel 7y ago

SPIR-V “assembly” can be disassembled, the disassembly is fairly easy to read, and it's not that hard to write by hand, though rather verbose. An advantage of SPIR-V is that unlike both text-based programming languages and traditional machine code, SPIR-V is very very easy for machines to read and write — even for JS code — and it has a structure designed to be (mostly) cleanly extensible.

banachtarski 7y ago

As someone who has written in every shader dialect and also dealt with bytecode for all the major consoles, I think SPIR-V is really awesome tbh... The thing is, a text format is the worst format for interoperability between consoles, desktop and web. Having something like SPIR-V is more akin to LLVM for programming languages. LLVM doesn't preclude the existence of C, C++, etc, but it strictly benefits the ecosystem (which now includes Rust, Haskell, etc). In the same way, I see SPIR-V having the same potential as the interchange format for all the major IHVs.