Is this worth it? about pyshader HOT 9 CLOSED

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.

from pyshader.

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.

from pyshader.

But perhaps we should give it a bit more time:

(this was 16-02-2021)

from pyshader.

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.

from pyshader.

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)

from pyshader.

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

from pyshader.

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.

from pyshader.

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.

from pyshader.

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.

from pyshader.