Project scope about pyshader HOT 9 CLOSED

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.

from pyshader.

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

from pyshader.

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

from pyshader.

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

from pyshader.

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/).

from pyshader.

@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

from pyshader.

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.

from pyshader.

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 :)

from pyshader.

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.

from pyshader.