Is this worth it?

[almarklein]

The idea for PyShader is based on the following advantages:

• People can write in a language they are familiar with, and use the same tools for e.g. linting. I still think this is true, but writing shaders requires a very specific way of thinking anyway. Is the familiar spelling worth it?
• Re-using code is easier, because you can simply call out to other (Python) functions. This can be done because the compiler understands the code and recognizes function calls, which can be used to detect these functions in the same code, to compile these too. However, there are other cases of code-reuse, more in the range of templating, that are need to make writing shaders not a pain.
• No need to pre-compile GLSL, or require users to install a compiler toolchain. This advantage is removed with WGSL and Naga.
• It's simply cool that you can write a shader in Python. This still holds :)

Disadvantages:

• Having yet another shading language can make things harder. E.g. to re-use shaders from elsewhere you need to rewrite in Python. Ask a question about shaders on SO?
• Maintenance. Python bytecode is not well defined. We need to reverse-engineer things for every new Python version. And there's pypy too.

I think that for pygx we need to consider WGSL too.

[ivoflipse]

I think it would at least be great for pygfx if pyshader was optional. If you already have a shader, then you should be able to use it.

[almarklein]

Yes, this is already the case. As in, the given shader must be SpirV, it's up to you how to get there. But now (or soon, I'm not 100% sure) you can also pass WGSL shaders, which solves at least one of the above issues.

[almarklein]

But perhaps we should give it a bit more time: (this was 16-02-2021)

[Korijn]

On its own, pyshader is a cool toy. But I don't think it's more than that and I would prefer to follow the industry standard in pygfx, whatever that may be. GLSL seems to be the most widely used, I don't know about WGSL yet, but I think both can compile to SpirV and should be most familiar to developers.

However, there are other cases of code-reuse, more in the range of templating, that are need to make writing shaders not a pain.

For me, this in particular totally defeated the point of pyshader, sadly. I had hoped to see this problem vanish (as was originally your expectation/vision, right?). But now that we can see it is unavoidable, it's not worthwhile for me anymore to learn another shading language + tool when I already know how to work with existing languages like GLSL.

I would prefer canning this and switching to a standard toolchain. From wgpu-rs, that seems to be:

Currently, shaders in the examples are written in GLSL 4.50 and compiled to SPIR-V manually. In the future WGSL will be the shader language for WebGPU, but support is not implemented yet.

For now, the shaders can be compiled to SPIR-V by running make, which requires you to have glslangs glslangValidator binary.

[almarklein]

I had hoped to see this problem vanish (as was originally your expectation/vision, right?).

Indeed it was. I had thought the ability to just call other functions would be enough, but this does not help introducing small variations in shaders, e.g. w.r.t. rgb/rgba/grayscale, texture formats, etc. Perhaps this needs a bit of though to see if we did not miss a possible avenue ...

But even then, using a shader language that nobody else knows, and having to maintain the compiler comes at a cost.

For me, the fact that WGSL seems to become the shading language for WebGPU, which was not so clear a year ago, I think, is the main reason to reconsider the viability of this tool.

... but support is not implemented yet.

I think this is changing right now. The examples in wgpu-rs now use WGSL! (since like a few weeks ago)

[Korijn]

For me, the fact that WGSL seems to become the shading language for WebGPU, which was not so clear a year ago, I think, is the main reason to reconsider the viability of this tool.

Can you explain what you think WGSL brings to the table that GLSL does not? Just curious :)

[almarklein]

Well, eventually it will be a very widely used shader format, since the intend is for this to be THE way to write shaders for the web. One of the ideas is that it maps rather directly to SpirV, so it may feel quite "clean". Shaders won't need to be compiled beforehand, though that may be true for glsl too, since that seems to be the on the roadmap: https://github.com/gfx-rs/naga

Once wgpu-py is updated to the latest wgpu-native, we can start playing with WGSL and see how well it works.

[Korijn]

I hope it doesn't have the same limitations as the web :) but it's looking promising indeed. I can also see how people would see it as a much more worthwhile exercise to learn WGSL, since it would be a skill they can apply outside pygfx as well.

[Korijn]

I think we've reached the conclusion on this one: we are going to stop pyshader development and switch wgpu-py and pygfx over to WGSL.

We should probably put a big notice at the top of the readme and archive this repo.