Adding a non semantic keyword in GLSL

Feature requests
1

Hello, I work for LunarG and helping maintain GLSL/glslang

I am aware babylon.js has to likely generate GLSL in order to target WebGL

If this is true, is there any use/desire in adding a [[non_semantic("some info")]] keyword into GLSL language? (Realize this is less of a issue and more of a “can I help?”)

The idea is that if there is logic in this repo where you have data you wish you could just save in your GLSL for convenience and not have glslang (browsers) yell at you, I would love to add something like to to GLSL for you? (But I have zero knowledge how you generate GLSL)

1 Like
2

cc @Evgeni_Popov @sebavan

3

Welcome aboard and thanks for offering to help!

We haven’t needed it so far, so I’m not sure we need such a feature, but I’ll cc @Deltakosh in case I’ve missed something.

Note that we only generate GLSL for node materials; otherwise, all shaders are already written in GLSL (and WGSL for WebGPU).

1 Like
4

We did not get the ask so far so I would say probably not:)

We are leveraging comments most of the time if we need to annotate generated code.

Do you mind sharing use cases maybe?

5

So at a conference last week, I met an experienced tech artist who talked about how important it was to make writing shaders easier for artist via node graph based UI

So what I learned from him experience working at Unity’s node graph system is they would take nodes, and generate code and wasted time removing thing to make the shader code “valid”

So if you have a robust system of leveraging comments, then glad it works… I guess probably years late now, but the idea was instead of hacking things with comments, there could have been a non-semantic keyword in GLSL itself that could have been used instead

… so ya, if there is no “omg please yes that would allow us to remove this hacky code”, then happy to just close/end this discussion

6

Unity are using HLSL which are then cross compiled to GLSL for target platforms. Hence, their extra step.

BabylonJS(bjs) works directly with glsl/wgsl shaders and provides tools for users to write their own shaders/inject custom shader codes/utilize the various node-graph based workflows for the same.

I am however curious whether LunarG maintains WGSL? As a bjs user, I feel wgsl debugging worse than glsl’s. Not sure whose responsibility it falls under in the entire toolchain…

7

Currently LunarG is not actively involved in WebGPU (we have people looking into it yet)

I know there is the WESL project run by the WebGPU tooling group to add things like testing, server protocol, etc

Talking to WebGPU people (who ultimately target Vulkan, hence meeting them) I know they would LOVE to hear your concern about what makes it harder to debug, I know they are all hard at work trying to build a whole new API

1 Like