Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brain dump on all things wrong with WGSL #2048

Closed
morganbarrett opened this issue Aug 19, 2021 · 9 comments
Closed

Brain dump on all things wrong with WGSL #2048

morganbarrett opened this issue Aug 19, 2021 · 9 comments
Labels
wgsl WebGPU Shading Language Issues

Comments

@morganbarrett
Copy link

So WGSL is meant to be the de facto shader language for the web, designed solely for the needs of the web. The cpu equivalent of this is Javascript which is obviously what WGSL is used with. So my main question would be why it takes inspiration (in terms of purely syntactical sugar) from everything but Javascript and its influencers. Below are all the idiosyncrasies that annoy me and are sure to cause trouble for anyone starting out in the future.

Loop

I don't understand what is to be gained by loop {...if(cond){ break; }...}, why not while and do while, it is trivial to translate.

(De)increment

Like this is an easy one, no? The prefix version at least.

Let

I don't even need to explain this one, let should be const.

Fn

Same goes as above, this should be function surely?

Vec3<f32>

I've seen this one mentioned already, I'm assuming one can't make a vector of a custom structure, if so the abstract type thing really doesn't make sense and is a pain in the ass to write. vec4f vec2i vec3u this sort of thing?

->

The type hinting already very closely resembles typescript/flow, so it might make more sense to take inspiration from here for return types. Instead of fn test(i: u32) -> u32 { would be better as function test(i: u32): u32 {.

std

I've seen the standard library mentioned as well and for the sake of learning curve, code completion and coming from js, would work better modularised e.g Math.cos(x) Vector.dot(x, y) Array.length(arr).

[[block]]

The double bracket expressions would be more familiar as @ expressions.

Blockless ifs

if(true) hi();

420u

I think unsigned ints should be un postfixed and signed ints should start with +/-.

Storage

var<uniform> blah do something, anything, differently.

@morganbarrett morganbarrett added the wgsl WebGPU Shading Language Issues label Aug 19, 2021
@kainino0x
Copy link
Contributor

I don't understand what is to be gained by loop {...if(cond){ break; }...}, why not while and do while, it is trivial to translate.

WGSL has for loops.

I don't even need to explain this one, let should be const.

Calling it const is a javascriptism, but in fact it does not match the semantics of javascript const anyway as it refers to a constant value, not a constant variable reference to a mutable value.

I've seen this one mentioned already, I'm assuming one can't make a vector of a custom structure, if so the abstract type thing really doesn't make sense and is a pain in the ass to write. vec4f vec2i vec3u this sort of thing?

There will be types like f64, f16, i8, u16, etc. in the future.

The double bracket expressions would be more familiar as @ expressions.

The syntax is adopted from C++.

I think unsigned ints should be un postfixed and signed ints should start with +/-.

This would be quite weird, I've never seen precedent for this.

var<uniform> blah do something, anything, differently.

Why? Do you have a proposal? A lot of design work went into this and I think we're pretty confident about it now (though there are some related things that may change soon).

@morganbarrett
Copy link
Author

WGSL has for loops.

But not while or do while loops.

Calling it const is a javascriptism, but in fact it does not match the semantics of javascript const anyway as it refers to a constant value, not a constant variable reference to a mutable value.

But why let? I think it's a bad choice.

There will be types like f64, f16, i8, u16, etc. in the future.

I quite like the Uint8Array style of js, maybe Uint8Vec3?

The syntax is adopted from C++.

Fair enough, that one is not too bad.

This would be quite weird, I've never seen precedent for this.

Weird... or cool?

Why? Do you have a proposal? A lot of design work went into this and I think we're pretty confident about it now (though there are some related things that may change soon).

No, this is the least of my issues with this, but I don't like how it is after the var.

@kainino0x
Copy link
Contributor

But why let? I think it's a bad choice.

Precedent from mathematics and functional programming languages.

(Sorry I haven't replied to everything, anything I didn't reply on I just didn't have anything in particular to say about)

@morganbarrett
Copy link
Author

No worries, I appreciate your answers, without any insight it just seems like a mismatch of randomness. I just worry some of the issues such at let will lead to a really frustrating workflow when going between js and wgsl, it reminds me of going back and forth between php and js, absolute hell.

@esoterra
Copy link

Isn't the CPU equivalent WASM?

The cpu equivalent of this is Javascript...

@munrocket
Copy link
Contributor

Loop, let, fn, vec3, ->

WGSL inspired by Rust. It looks pretty good if you think of it like a Rust'y version of GLSL.

let vs var is confusing javascript comunity

Agree that this looks weird for web developers. Maybe rename var -> mut and make WGSL even more Rust'y?

Storage

I guess this is similar to #1975

@morganbarrett
Copy link
Author

Yeah, I think if it was all very "Rust'y" it wouldn't be as bad (yet still confusing). I've decided to just write a babel plugin, so I can use ordinary js and transpile it to wgsl, in a similar vein to gpujs. With added benefits of being able to reuse the functions on cpu and automatic configuration of buffers inferred from use.

@munrocket
Copy link
Contributor

@morganbarrett nice idea, some fast computation or quick sorting can be useful.

Since WGSL is a new shader language for web (and pc too), we can try to make it little bit more dev friendly before standard is finalised.

For example smoothStep() overload would be useful too, like mentioned in #1974. Or I thought about vector component assignment. Don’t know why it’s not possible, maybe some issue with native API.

@kdashg
Copy link
Contributor

kdashg commented Sep 22, 2021

Thanks for the feedback!
Let's open individual issues for any of these points that you want to continue discussing, please!

@kdashg kdashg closed this as completed Sep 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wgsl WebGPU Shading Language Issues
Projects
None yet
Development

No branches or pull requests

5 participants