Fwd: [webgpu] Add the `import` keyword or some equivalent

For Vulkan and SPIR-V I meant WGSL is not a great replacement as a language
like Vulkan or a target like SPIR-V. I think a lot of these problems are
caused by the nature of WGSL seemingly trying to be both a targetable API
and a language in it of itself. As a result it gives up on benefits like
being able to be an easy target or the efficiency gains of bytecode like
targets such as WASM and SPIR-V while also lacking a lot of I'd argue
essential language features like `include`. In my view I think that WebGPU
should lean into more of being a language and thus include these
functionalities or lean into more of being a target so that tooling
targeting it makes sense. As it stands now it's in an intermediary position
where it doesn't satisfactorily do either. There are clearly some languages
that target compilation to WGSL but these are inevitably going to run into
the same issues that languages targeting JS ran into by being an
abstraction of an abstraction. I think the WESL language is the best thus
far for targeting WGSL but now tooling will have to make a choice, focus on
handling WESL or WGSL. If WebGPU is only a target then it makes sense to
focus on WESL but if WGSL is a language then tooling should target it most.
WESL is simple enough at this point that a simple compilation run could
allow tools built for WGSL to work with it, but I'm concerned that as the
APIs complexity increases and others want more features in languages that
target WebGPU we're going to create a painful standard with painful
tooling. Though throughout this I think Lee is correct that trying this out
in a separate library first to determine the effectiveness, desire, and
problems they may present is extremely important. If that's the primary
focus on WESL as trying out experimental features I think it's great.

Long and short I think that WebGPU API should lean into being a language
more than a standard and thus include things such as `include` or `use`.
Either that or it should simplify itself as a target and avoid using a
formal language, instead enabling both a text based and byte code based
format like `.wat` and `.wasm` for WASM. (I understand through some online
readings that there are security concerns with bytecode for WebGPU but
bluntly I don't understand them, so feel free to correct me here if that's
not practically possible). I think the core of the difficulty of this
request is I'm interpreting WGSL as a language rather than a target due to
the language being really quite nice to work with most of the time and
being extremely portable (As it's the most consistent multi-platform
language I've experienced, beyond even SPIR-V).

Separately though, I think as Brendan pointed out correctly this issue has
already been discussed, and while I disagree that external tooling is
better than language features I think this is mostly due to a different
goal in mind about what WebGPU should try to be. I will as Gregg suggested
try Slang as that seems to be most proximal to what I want in a shading
language (I didn't know it existed so thank you very much for telling me).

On Fri, Jan 17, 2025, 3:14 PM Gregg Tavares <gman@google.com> wrote:

>
>
> On Fri, Jan 17, 2025 at 8:40 AM Brendan Duncan <brendan.duncan@unity3d.com>
> wrote:
>
>> This was discussed at https://github.com/gpuweb/gpuweb/issues/741, and
>> https://github.com/gpuweb/gpuweb/issues/568.
>>
>> Personally, I think it could be done better as third-party code using
>> string manipulation, rather than via shader module dependency tracking
>> within the api. External tools can be implemented easily enough to provide
>> that functionality. Some have already been developed.
>>
>> On Fri, Jan 17, 2025 at 1:13 AM Rowan Fraser <beanfun1@gmail.com> wrote:
>>
>>> Hello W3 Consortium,
>>> I want to work with WGSL and WebGPU but the inability to have any kind
>>> of import or library or modulation mechanism is crippling to any real-world
>>> development in the language. It isn't possible currently to have reasonably
>>> sized scriptis, instead I'm forced to jump around to different commented
>>> sections. I would like to use WGPU as a universal shading language but as
>>> it stands the inconvenience of that (along with other tooling issues) makes
>>> it an unsuitable replacement for tools such as Vulkan and SPIR-V.
>>>
>>
> You mentioned Vulkan and SPIR-V works better in this regard? But isn't
> that path even worse? AFAIK, few people write SPIR-V, instead they use some
> external tool to convert something like GLSL into SPIR-V. Maybe you've been
> using an external solution for so long you forgot it was just that, an
> *external* solution?
>
>
>> I think that one key functionality would do a great deal to open up
>>> development as it would allow passing around of functional libraries while
>>> also preventing WGSL scripts from becoming too bloated.
>>> Thank you for your time,
>>> From Rowan Fraser
>>>
>>
> I agree with Brendan. This is best performed outside of the API. That
> keeps the API simple and lets the solution chosen be as complex or as
> simple as desired. New features can be added as well without having to wait
> for every WebGPU implementation to add them.
>
> Some existing solutions in order of complexity:
>
> * https://github.com/toji/wgsl-preprocessor
> * https://github.com/wgsl-tooling-wg/wesl-js
> * https://github.com/shader-slang/slang
>
>
>
>