Project scope

[almarklein]

I have doubts whether the current scope makes much sense:

• The raw bytes2spirv and file2spirv feel silly.
• The glsl compiler functionality need the sdk tools, so should really only be used by devs in a pre-build step, and then this friendly API is not really needed; calling glslc in a subprocess is then the easy part.
• By far the most code is about the Python2spirv compiler. And this is code is also the main motivation for this package.
• There is an odd mix of functions that work everywhere and functions that need the vulkan sdk to be installed. The latter are intended for devs and should probably not end up in user code.
• I also fear that with the current scope we may shift towards eventually packing the vulkan sdk ... and I don't want to go there ...

I think I want to refactor this to be:

• A python to (our own) bytecode compiler.
• A bytecode to spirv compiler.
• A single decorator that can be used on a Python function to create a shader in end-user code.

Then when WebGPU becomes a thing we may add, if it makes sense:

• A WSL to bytecode "front end".
• An output format other than Spirv (or subset?).

[Korijn]

No objections from my end. "Do One Thing And Do It Well"!

[almarklein]

@windelbouwman we can still continue with WASL (within this project), but we should probably just rename it to WSL and adopt the corresponding syntax ;)

[Korijn]

What exactly are WSL and WASL? I only know WSL as the Windows Subsystem for Linux. :')

[windelbouwman]

WASL stands for "Windel Almar Shading Language", proposed as an alternative to coding shaders in some dialect of C, which might suck :). WSL I also know as Windows Subsystem for Linux, but also appears to be WebGPU Shading Language (https://gpuweb.github.io/WSL/).

[windelbouwman]

@almarklein WSL looks interesting, also interesting we missed it and invented our own language :). Is it an improvement over C based shader language?

If you want to write a compiler for WSL, you might want to switch from textx to lark: https://github.com/lark-parser/lark

[almarklein]

Is it an improvement over C based shader language?

I have not looked into it much yet. I suspect that it will look similar to GLSL. Though there are e.g. keywords vertex, fragment and compute to mark functions as entry point for these shader stages.

[almarklein]

BTW: keeping WASL somewhat alive (or making a start on WSL) is still interesting to force us to keep the abstractions right; if we had only one path (Python->bytecode->spirv) it might be tempting to make shortcuts.

[Korijn]

Just so I understand it right, this library (spirv-py) would go from python code to spir-v, right? So then, GLSL, WSL and WASL would be alternatives to python as input for the front-end of this library.

Seems like it would be nice to have a uniform Python API for all shader formats users might bring, but on the other hand, there already are conversion tools being developed for these other formats externally right? Like the vulkan-sdk!

Perhaps it would be better to write an "umbrella" python library separately later, and have it treat spirv-py as an optional front-end just like the other external tools?

[Edit] that might be a nice visvis2 module, actually :)

[almarklein]

Yeah, in theory we can add a front-end that can consume GLSL. But writing this in Python is quite an effort, and using the Vulkan SDK gets us an annoying dependency. Therefore I want to keep GLSL out of the scope of this project.

If WSL is a well defined format, it may be worth looking into compiling that to the bytecode that we use internally as an IR.

On the backend, we now generate SpirV from our bytecode. If WebGPU turns out not to consume SpirV but another format, we can add a generator for that. A GLSL generator would also be feasible, actually.

Perhaps it would be better to write an "umbrella" python library separately later, and have it treat spirv-py as an optional front-end just like the other external tools?

Yeah, perhaps. I guess it depends a lot on what WebGPU will look like in terms of shaders.