13 ms·

First Public Working Drafts: WebGPU and WebGPU Shading Language

163 points by bpierre 5y ago

gsnedders 5y ago
For those unfamiliar with the W3C: Working Drafts are essentially just "drafts with stable URLs for review purposes and historical interest". First Public Working Drafts also have consequences under the W3C Patent Policy, primarily starting a timer under which any participant of the group has to say they wish to exclude any patents they hold from the W3C royalty-free grant.
adamnemecek 5y ago
You should check out the Rust WebGPU implementation https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs
- mrec 5y ago
  https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu is the actual implementation (in Rust, but exposing a C API). wgpu-rs is an idiomatic wrapper around that.
  - adamnemecek 5y ago
    I know and I considered for a second which one to link to and I went with the Rust bindings.
pjmlp 5y ago
I find interesting that WGSL is clearly influenced by Rust. GSL and WGSL are completely unrelated, apparently time to rewrite shaders. And in what concerns debugging, better get good at understanding what is the actual application code and browser own rendering engine, as the best solution keeps being to use native GPGPU debuggers.
- corysama 5y ago
  From what little I know, they were mostly influenced by who showed up. A lot of Rusties participated.
  - kvark 5y ago
    This isn't actually the reason. The first draft of WGSL, proposed by Google team, already had Rust-like syntax. As far as I'm aware, nobody from that team had any significant work done in Rust.
raphlinus 5y ago
I've been doing something of a deep dive into the suitability of WebGPU and WGSL for "serious" compute tasks (ie potentially competing with CUDA). Here's my take on the current state. The upside is that it's very pleasant to program compared with existing APIs, and is portable. Even when the GPU doesn't quite meet the requirements, it's possible to polyfill compute shaders with SwiftShader. As this standard becomes more mature, it will be reasonable to expect that it will be correct and performant pretty much everywhere. Note that both web and non-web implementations are viable. The biggest drawback is that the "MVP" covers the basics of compute shaders but not the advanced features. It's roughly equivalent to DX11 / Shader Model 5, which is of course good for compatibility on pre-Windows 10 devices. It's missing subgroup operations, scalar types other than 32 bits, an explicit memory model, and some other goodies. This potentially leaves quite a bit of performance on the table, but that will depend on the exact workload. For example, machine learning inference workloads will probably suffer considerably due to the lack of f16. Thus, if you want to ship something based on compute shaders today, it makes sense to build your own portability layer on top of existing APIs such as Vulkan, DX12, and Metal. I do think WebGPU is an excellent on-ramp to learning compute shader programming, as it will get stronger over time, and concepts will transfer to other APIs as listed above. Watch my Twitter feed for more depth on the points I listed above.
- longstation 5y ago
  Could someone correct me? I am pretty new to graphics programing but I was learning wgpu (the Rust binding of WebGPU) the other day. I was under the impression that the shader language is GLSL (version 450) and it is then converted into SPIR-V. Would those limitations still apply with SPIR-V?
  - lights0123 5y ago
    The shader language you write in does not matter, as it can be converted into whatever format the API expects. wgpu historically accepts SPIR-V, but the latest version released ~a month ago has moved to WGSL as much as it can in the examples. Have you upgraded yet?
throwaway34241 5y ago
For anyone unfamiliar with WebGPU: It's a successor to WebGL, along the lines of newer graphics APIs like Metal/Vulkan/DirectX 12. Google and Mozilla are also developing a C-compatible library that should be available as an OpenGL alternative for native code. So if successful it might end up as the most convenient cross-platform graphics library (across desktop/mobile/the web). Currently the alternatives in this space are: - OpenGL (which Apple has deprecated and is stuck on an older version on their platforms) - Vulkan, which is the lowest level and most difficult to get started on of the APIs, and also doesn't work on the web, but is supported on Apple systems by using the MoltenVK library to translate it to Metal - some non-standardized libraries written by third party developers like bgfx and Oryol. For the shading language they settled on a text based language designed to be easily translatable to/from Vulkan SPIR-V bytecode, with the goal of being able to re-use existing shader compilation toolchains (and most of the work put in to SPIR-V), while still having the ability to write/read shaders without a shader compiler. Also SPIR-V files are fairly large and apparently don't compress well with standard algorithms (see SMOL-V) so the text based format should probably be more efficient to transmit on the web.
- mebr 5y ago
  A question, I was wondering if you happen to know whether there is a long term commitment from these orgs/companies to support WebGPU, say for at least 10 years?
  - throwaway34241 5y ago
    If it's approved as a web standard, I would expect them to support it basically forever, since otherwise websites would stop working. I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago.
    - rewq4321 5y ago
      > I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago There's basically zero uncertainty around this. It would break the internet. As you probably know it's extremely difficult to make even tiny backwards-incompatible changes to features that have become web standards and have been implemented on all major browsers.
waynecochran 5y ago
It would be cool if the shading document has an example ... just diving into details makes it hard to get the flavor. Anyone have a smallish SL example?
- raphlinus 5y ago
  https://github.com/austinEng/webgpu-samples https://github.com/austinEng/webgpu-samples is your friend. Look under sample/*/*.wgsl in particular for shader examples.
mrweasel 5y ago
I was looking under security and I don’t see any mention of misuse, but that can also be hard to identify. Potential misuse should not stop WebGPU from moving forward, but isn’t there a concern that the make JavaScript injection attacks more attractive? Rather than buying and operate a crypto mining setup it now becomes more attractive to attempt to utilize the GPUs of unsuspecting web users. Or am I misunderstanding how much of the GPU this will grant you access to?
- modeless 5y ago
  The GPU is already accessible to JavaScript through WebGL. WebGPU should hopefully be somewhat faster in many cases, and simpler to use with a simpler/less buggy implementation. But it's not really exposing a ton of attack surface that's not already available in WebGL. Things like coin mining are already possible with WebGL, and a small-to-medium sized speed boost isn't going to change much. Neither WebGL nor WebGPU will today give you 100% of native (e.g. CUDA) performance for applications like coin mining or machine learning. And even WebGPU may never get all the way there, at least in a form that can be exposed in browsers, because top performance requires deep knowledge of the user's specific hardware configuration and specialized hardware-specific code paths. Exposing that to the web raises legitimate fingerprinting and portability concerns. That said, I think there is a lot of promise for WebGPU as a portable graphics API for native applications outside of browsers, where said fingerprinting and portability concerns are much less of an issue. In a native context, hardware-specific extensions could easily be exposed and there's no reason in theory why you couldn't have the best performance possible on any given hardware.
  - Hizonner 5y ago
    > The GPU is already accessible to JavaScript through WebGL. Mine isn't. Disabling WebGL is DEFINITELY on the checklist for a new browser profile GPUs are way too complicated, way too opaque, and way too privileged to be safely exposed to the Web. We're not talking about some Web page using your machine to mine crypto here. We're talking about some Web page owning your kernel. Kill it with fire.
    - 5y ago
brrrrrm 5y ago
the performance is pretty impressive on some devices https://news.ycombinator.com/item?id=26333369 https://news.ycombinator.com/item?id=26333369
- kvark 5y ago
  This benchmark has little to do with the first public draft of the API we are discussing. Safari's old implementation hasn't been updated in years, and it's probably missing all the safety checks we'll need to ship this, such as array out-of-bound access handling.
slmjkdbtl 5y ago
I'm looking at the complex specs of the shading language which accomplish almost the same thing as other modern high level shading languages, and thinking is there any possibility we'll reach a state of consensus on a single unified GPU graphics interface? Right now things seem to go more fragmented instead of unified, we moved away from "cross-platform" OpenGL to extremely vendor specific Vulkan, Metal, D3d and WebGPU, looks like cross platform graphics programming is becoming more and more far away, have to rely on abstraction layer which are often huge dependencies and tedious to develop / maintain.
- kvark 5y ago
  WebGPU on native is the best bet to bring back the times where you could reasonably write once and run everywhere. See also - http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html http://kvark.github.io/web/gpu/native/2020/05/03/point-of-we...
  - slmjkdbtl 5y ago
    Thanks for the article it's a great write up! Do you mean it's possible in the future venders will ship WebGPU drivers built in their product (couldn't find any evidence on that yet) or it's the best option for the interface of a translation layer like wgpu? Right now wgpu is already pretty solid as a translation layer, but direct driver support will be so good. (Also thanks for your works on Rust graphics related stuff! They benefit me a lot)
    - kvark 5y ago
      I don't expect any driver support for this in the nearest future. The promise of WebGPU on native is not in wgpu library quality, although it's a part of the equation. The promise is in a well-thought specification (of WebGPU API) and the standardized API headers with multiple implementations. This matches best practices from Khronos.
  - pjmlp 5y ago
    I consider that is best served by middleware engines taking the best advantage of each platform main API. WebGPU still isn't at the same comfort level as the frameworks provided by platform owners for their APIs.
jmrm 5y ago
I imagine that this, in addition to WebAssembly, could lead in the future to playing more complex games from the browser with the benefit of being platform agnostic (in kind of device, hardware architecture, OS) as long as the browser, the OS, and the hardware is compatible. Am I wrong?
- flohofwoe 5y ago
  The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games. Some examples: - The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers. - Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate) - WebAudio is ... I don't even know what... all we need is simple buffer streaming but we got this monstrosity of a node-based audio API. And the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre. - Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels). ...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different and very specific high-level use cases (such as creating an audio synthesizer in a webpage, or creating a video chat solution for browsers), and those rigid high-level APIs are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games. This isn't a new idea, see the Extensible Web Manifesto: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ (backup: https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto) But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).
  - 5y ago
bruce343434 5y ago
Yuck. So now there's 3 of them. What's wrong with GLSL? HLSL? Somebody link that xkcd about competing standards. But seriously, why do they reinvent the wheel? Either make javascript work on the GPU (because that's the language of the web, just like C++ and Cuda go hand in hand), or just stick with HLSL.
- kvark 5y ago
  Apple has tried to collaborate with Microsoft on making HLSL viable for the Web and standardizing it. IIRC, we figured that we can't accept HLSL as is anyway, and we'd have to develop a flavor of it for the Web, in which case the point about using an existing language becomes moot.
- rektide 5y ago
  Control-flow oriented languages like JavaScript are not a good fit for GPUs. That's the accepted belief, at least. Allegedly GLSL and HLSL do not come with enough protections / guarantees for anyone to have felt comfortable porting them to the web. That rules them out cleanly. Also, these are both fairly legacy technologies, both predating Vulkan by a good bit more than a decade. WebGPU at it's core is a remake of Vulkan for the web. Then there's a shading language that works with this base. My understanding is this is a far more competent, capable means of setting up & orchestrating work, so that it can happen & flow effectively on GPUs. Doing less than WebGPU sounds supremely unappealing.
rektide 5y ago
Maybe worth noting that Deno 1.8 has WebGPU support[1]. Deno's quest to be the web-platform compatible alternative to Node is expansive & impressive!! I have high hopes for it! [1] https://deno.com/blog/v1.8 https://deno.com/blog/v1.8 https://news.ycombinator.com/item?id=26323600 https://news.ycombinator.com/item?id=26323600
Jakobeha 5y ago
Idk if WebGPU will ever be fully supported by enough browsers to be viable for the web. Even if it is eventually supported people are saying it will take 10+ years. I do think WebGPU can be a great cross-platform compute shader framework outside of the web. My experience with compute shaders is that they're really really platform specific: you need not just the right OS, but also the right graphics chip. It would be nice to write cross-platform high-end 3D apps without relying on Unity or Unreal. Also, hopefully WebGPU has better debugging tools (if they're even possible). I tried GPU programming before but it's a mess: almost every example I tried to run crashed terribly (e.g. system reboot), and even at best, I couldn't get much debugging output other than "code = problem".
- rewq4321 5y ago
  > people are saying it will take 10+ years Who is saying that? Genuinely curious. It has strong buy-in from Apple, Google and Mozilla, and all 3 are implementing the spec right now (and updating implementations as the spec changes). Seems very doubtful that it'd take anywhere near 10 years to be supported by major browsers. I guess it depends on what subset of graphics/compute features you need for it to be viable for your specific use case.
  - Jakobeha 5y ago
    Ok, maybe not 10 years. But look at WebGL2. From wikipedia: > Development of the WebGL 2 specification started in 2013 with final in January 2017 Moreover, WebGL2 support was only added to Edge since January 2020, and as of now it's still not supported in Safari (excluding Safari TP) (from https://caniuse.com/webgl2 https://caniuse.com/webgl2).
    - rewq4321 5y ago
      I don't think you's want to use WebGL2 as an analogue here. Radically different depth and breadth of buy-in across the browser ecosystem. I'm no expert, but I'm genuinely curious where you got the 10+ year figure from (is there an up-to-date estimate/roadmap from any of the people working on this?). I was under the impression that we'd see an MVP stabilise relatively soon (i.e. within a couple of years at most). Of course, there will still be features being added in 10 years time, since graphics APIs and GPUs are always evolving.
rubatuga 5y ago
You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buffer (which required a restart), completely frozen the GPU, and can consistently trigger denial of service attacks. I can guarantee that WebGPU opens a huge attack space that is relatively unexplored.
- kvark 5y ago
  The current implementations are heavy WIP and incomplete. The fact that you managed to screw them up is not a big surprise. Once all of the safety and validation work is done, we'll need to check again and see.
  - TonyTrapp 5y ago
    Those bugs are in the graphics drivers, not in the WebGPU implementation. Any remotely powerful GPU interface will probably be able to talk to the drivers in a way that will exploit those bugs. On the other hand, if you artificially restrict the interface so those bugs are out of reach, it will probably not be powerful enough for what it wants to be. Graphics card vendors will have to step up their game and improve their drivers.
- anentropic 5y ago
  It feels like this is something a "Web-" prefixed API should protect us from. I'm curious if such catastrophic behaviour is inherent to the WebGPU API as specified, or of the current implementation is failing to provide the level of safety that it should according to the spec?
  - paulgb 5y ago
    > It feels like this is something a "Web-" prefixed API should protect us from. It's worth noting here that the Python wgpu library (which I'm assuming is the one GP is referring to?) is a WebGPU-inspired API to wgpu. wgpu is the library that Mozilla created as a native graphics abstraction layer to build WebGPU on top of. It's possible that Mozilla has implemented (or intends to implement) the security/validity checks between wgpu and the JavaScript interface exposed to the browser, in which case they would not automatically apply to the Python bindings.
baybal2 5y ago
The moment Google made js throttling to kill miners, miners switched to WebGL, and WASM. A WebGPU miner will be coming out the same second it is adopted.
- CyberDildonics 5y ago
  So what?
  - baybal2 5y ago
    It is bad
    - CyberDildonics 5y ago
      Why would it be? People can do what they want. It isn't hard to avoid.
      - baybal2 5y ago
        It will be hard to avoid if it will become omnipresent
        CyberDildonics 5y ago
        Are webGL and webasm mining "omnipresent" in web pages? What does that even mean exactly? You can turn off local storage, cookies, sound and javascript itself in per page permissions, you think every web page is going to have an unavoidable crypto currency miner embedded in it when webGPU becomes more common? Do you think that people won't be able to see that a specific iframe is using 99% of their GPU or do you think people will just live with it and won't care? I don't even think that you really believe this.
dindresto 5y ago
I took the opportunity to base my visual computing project for this semester on the Rust WebGPU implementation (wgpu-rs). Working with it is very nice, compared to OpenGL and Vulkan. The biggest pain point right now is WGSL because it still is a moving target, but it's already good enough to work with in my case. The repository for my project currently lacks any info at all unfortunately: https://github.com/niklaskorz/linon/ https://github.com/niklaskorz/linon/ It is a ray caster that I plan to evolve into a nonlinear ray caster where the viewing rays travel along a vector field which thus distorts the image. You can enable the nonlinear mode by setting the "linear_mode" constant in "src/compute.wgsl" to false. I also implemented hot reloading for the shaders, which made experimenting a lot easier. The project doesn't have any non-Rust dependencies, so giving it a go is as easy as "cargo run" in the repository directory. For an idea of what I'm aiming for, see the "Visualizing Strange Worlds" paper by Eduard Gröller from 1995: https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pdf https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pd... You can also drag&drop .obj models to load them, but I advise you to only use small models (500 triangles max) in linear mode and completely avoid it in nonlinear mode right now, as the performance is really bad at the moment. :) I'm looking into acceleration structures next, so hopefully this will improve.
Shadonototro 5y ago
--- [[stage(fragment)]] fn main() -> [[location(0)]] vec4<f32> { return vec4<f32>(0.4, 0.4, 0.8, 1.0); } --- That is very ugly and full of noise, c'mon people, that's one thing to like rust, but let's not import its ugly and noisy cluttered syntax..., it took me few seconds to understand what's going on there --- var<private> x: f32; --- let's not confuse things even more, we have vec4<f32> already, C'MON PEOPLE
- kvark 5y ago
  This is very similar to what you'd write in HLSL, except maybe for `[[stage(fragment)]]` part (since this information is provided externally in HLSL) and `vec4<f32>` instead of `float4`. Are these the only things you are concerned about? If so, then I'd be happy with this, given that it's an artificial example.
- bschwindHN 5y ago
  It's really not that bad. I had some complaints about WGSL a few months ago but it was surprising how quickly it improved. Here are some simple real-world shaders you can look at: https://github.com/bschwind/simple-game/tree/9de179085a04dd42c76bc3c39f88a54b1ba2b71f/src/graphics/shaders/wgsl https://github.com/bschwind/simple-game/tree/9de179085a04dd4... If you combine it with a quick build step to give you shader compilation errors before your program runs, it becomes a pretty nice shading language. There are still a few rough edges but it's not _that_ bad to work with.
PaulDavisThe1st 5y ago
So the long march towards the "other" future continues ... Failure #1: to get operating systems to ever agree on a truly common API for most modern computing Failure #2: to implement a write-once, run-anywhere language capable of being used for the majority of software development (mostly because the main efforts at doing so all rely on VMs that come with their own costs and benefits) Conclusion: just give up. Postulate the existence of a virtual machine inside a web browser. Spend a decade or three slowly extending the scope of that virtual machine. Put in a little bit of effort to persuade people that this new, evolving VM is the new key to "write once, run anywhere". Result: a new platform, distinct from all the rest (i.e. "native") with its own costs and benefits. Whoo-hoo.
- kvark 5y ago
  I very much share this concern, wrote about this semi-recently in http://kvark.github.io/web/platform/2020/09/30/platform-wars.html http://kvark.github.io/web/platform/2020/09/30/platform-wars...
eptcyka 5y ago
I fear this does nothing to prevent fingerprinting via your GPU.
boltzmann_brain 5y ago
Yes, we definitely need more shading languages.

163 points by bpierre 5y ago

For those unfamiliar with the W3C: Working Drafts are essentially just "drafts with stable URLs for review purposes and historical interest". First Public Working Drafts also have consequences under the W3C Patent Policy, primarily starting a timer under which any participant of the group has to say they wish to exclude any patents they hold from the W3C royalty-free grant.

adamnemecek 5y ago

You should check out the Rust WebGPU implementation https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs

mrec 5y ago
https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu is the actual implementation (in Rust, but exposing a C API). wgpu-rs is an idiomatic wrapper around that.
- adamnemecek 5y ago
  I know and I considered for a second which one to link to and I went with the Rust bindings.

pjmlp 5y ago

I find interesting that WGSL is clearly influenced by Rust. GSL and WGSL are completely unrelated, apparently time to rewrite shaders. And in what concerns debugging, better get good at understanding what is the actual application code and browser own rendering engine, as the best solution keeps being to use native GPGPU debuggers.

corysama 5y ago
From what little I know, they were mostly influenced by who showed up. A lot of Rusties participated.
- kvark 5y ago
  This isn't actually the reason. The first draft of WGSL, proposed by Google team, already had Rust-like syntax. As far as I'm aware, nobody from that team had any significant work done in Rust.

raphlinus 5y ago

I've been doing something of a deep dive into the suitability of WebGPU and WGSL for "serious" compute tasks (ie potentially competing with CUDA). Here's my take on the current state. The upside is that it's very pleasant to program compared with existing APIs, and is portable. Even when the GPU doesn't quite meet the requirements, it's possible to polyfill compute shaders with SwiftShader. As this standard becomes more mature, it will be reasonable to expect that it will be correct and performant pretty much everywhere. Note that both web and non-web implementations are viable. The biggest drawback is that the "MVP" covers the basics of compute shaders but not the advanced features. It's roughly equivalent to DX11 / Shader Model 5, which is of course good for compatibility on pre-Windows 10 devices. It's missing subgroup operations, scalar types other than 32 bits, an explicit memory model, and some other goodies. This potentially leaves quite a bit of performance on the table, but that will depend on the exact workload. For example, machine learning inference workloads will probably suffer considerably due to the lack of f16. Thus, if you want to ship something based on compute shaders today, it makes sense to build your own portability layer on top of existing APIs such as Vulkan, DX12, and Metal. I do think WebGPU is an excellent on-ramp to learning compute shader programming, as it will get stronger over time, and concepts will transfer to other APIs as listed above. Watch my Twitter feed for more depth on the points I listed above.

longstation 5y ago
Could someone correct me? I am pretty new to graphics programing but I was learning wgpu (the Rust binding of WebGPU) the other day. I was under the impression that the shader language is GLSL (version 450) and it is then converted into SPIR-V. Would those limitations still apply with SPIR-V?
- lights0123 5y ago
  The shader language you write in does not matter, as it can be converted into whatever format the API expects. wgpu historically accepts SPIR-V, but the latest version released ~a month ago has moved to WGSL as much as it can in the examples. Have you upgraded yet?

throwaway34241 5y ago

For anyone unfamiliar with WebGPU: It's a successor to WebGL, along the lines of newer graphics APIs like Metal/Vulkan/DirectX 12. Google and Mozilla are also developing a C-compatible library that should be available as an OpenGL alternative for native code. So if successful it might end up as the most convenient cross-platform graphics library (across desktop/mobile/the web). Currently the alternatives in this space are: - OpenGL (which Apple has deprecated and is stuck on an older version on their platforms) - Vulkan, which is the lowest level and most difficult to get started on of the APIs, and also doesn't work on the web, but is supported on Apple systems by using the MoltenVK library to translate it to Metal - some non-standardized libraries written by third party developers like bgfx and Oryol. For the shading language they settled on a text based language designed to be easily translatable to/from Vulkan SPIR-V bytecode, with the goal of being able to re-use existing shader compilation toolchains (and most of the work put in to SPIR-V), while still having the ability to write/read shaders without a shader compiler. Also SPIR-V files are fairly large and apparently don't compress well with standard algorithms (see SMOL-V) so the text based format should probably be more efficient to transmit on the web.

mebr 5y ago
A question, I was wondering if you happen to know whether there is a long term commitment from these orgs/companies to support WebGPU, say for at least 10 years?
- throwaway34241 5y ago
  If it's approved as a web standard, I would expect them to support it basically forever, since otherwise websites would stop working. I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago.
  - rewq4321 5y ago
    > I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago There's basically zero uncertainty around this. It would break the internet. As you probably know it's extremely difficult to make even tiny backwards-incompatible changes to features that have become web standards and have been implemented on all major browsers.

waynecochran 5y ago

It would be cool if the shading document has an example ... just diving into details makes it hard to get the flavor. Anyone have a smallish SL example?

raphlinus 5y ago
https://github.com/austinEng/webgpu-samples https://github.com/austinEng/webgpu-samples is your friend. Look under sample/*/*.wgsl in particular for shader examples.

mrweasel 5y ago

I was looking under security and I don’t see any mention of misuse, but that can also be hard to identify. Potential misuse should not stop WebGPU from moving forward, but isn’t there a concern that the make JavaScript injection attacks more attractive? Rather than buying and operate a crypto mining setup it now becomes more attractive to attempt to utilize the GPUs of unsuspecting web users. Or am I misunderstanding how much of the GPU this will grant you access to?

modeless 5y ago
The GPU is already accessible to JavaScript through WebGL. WebGPU should hopefully be somewhat faster in many cases, and simpler to use with a simpler/less buggy implementation. But it's not really exposing a ton of attack surface that's not already available in WebGL. Things like coin mining are already possible with WebGL, and a small-to-medium sized speed boost isn't going to change much. Neither WebGL nor WebGPU will today give you 100% of native (e.g. CUDA) performance for applications like coin mining or machine learning. And even WebGPU may never get all the way there, at least in a form that can be exposed in browsers, because top performance requires deep knowledge of the user's specific hardware configuration and specialized hardware-specific code paths. Exposing that to the web raises legitimate fingerprinting and portability concerns. That said, I think there is a lot of promise for WebGPU as a portable graphics API for native applications outside of browsers, where said fingerprinting and portability concerns are much less of an issue. In a native context, hardware-specific extensions could easily be exposed and there's no reason in theory why you couldn't have the best performance possible on any given hardware.
- Hizonner 5y ago
  > The GPU is already accessible to JavaScript through WebGL. Mine isn't. Disabling WebGL is DEFINITELY on the checklist for a new browser profile GPUs are way too complicated, way too opaque, and way too privileged to be safely exposed to the Web. We're not talking about some Web page using your machine to mine crypto here. We're talking about some Web page owning your kernel. Kill it with fire.
  - 5y ago

brrrrrm 5y ago

the performance is pretty impressive on some devices https://news.ycombinator.com/item?id=26333369 https://news.ycombinator.com/item?id=26333369

kvark 5y ago
This benchmark has little to do with the first public draft of the API we are discussing. Safari's old implementation hasn't been updated in years, and it's probably missing all the safety checks we'll need to ship this, such as array out-of-bound access handling.

slmjkdbtl 5y ago

I'm looking at the complex specs of the shading language which accomplish almost the same thing as other modern high level shading languages, and thinking is there any possibility we'll reach a state of consensus on a single unified GPU graphics interface? Right now things seem to go more fragmented instead of unified, we moved away from "cross-platform" OpenGL to extremely vendor specific Vulkan, Metal, D3d and WebGPU, looks like cross platform graphics programming is becoming more and more far away, have to rely on abstraction layer which are often huge dependencies and tedious to develop / maintain.

kvark 5y ago
WebGPU on native is the best bet to bring back the times where you could reasonably write once and run everywhere. See also - http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html http://kvark.github.io/web/gpu/native/2020/05/03/point-of-we...
- slmjkdbtl 5y ago
  Thanks for the article it's a great write up! Do you mean it's possible in the future venders will ship WebGPU drivers built in their product (couldn't find any evidence on that yet) or it's the best option for the interface of a translation layer like wgpu? Right now wgpu is already pretty solid as a translation layer, but direct driver support will be so good. (Also thanks for your works on Rust graphics related stuff! They benefit me a lot)
  - kvark 5y ago
    I don't expect any driver support for this in the nearest future. The promise of WebGPU on native is not in wgpu library quality, although it's a part of the equation. The promise is in a well-thought specification (of WebGPU API) and the standardized API headers with multiple implementations. This matches best practices from Khronos.
- pjmlp 5y ago
  I consider that is best served by middleware engines taking the best advantage of each platform main API. WebGPU still isn't at the same comfort level as the frameworks provided by platform owners for their APIs.

jmrm 5y ago

I imagine that this, in addition to WebAssembly, could lead in the future to playing more complex games from the browser with the benefit of being platform agnostic (in kind of device, hardware architecture, OS) as long as the browser, the OS, and the hardware is compatible. Am I wrong?

flohofwoe 5y ago
The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games. Some examples: - The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers. - Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate) - WebAudio is ... I don't even know what... all we need is simple buffer streaming but we got this monstrosity of a node-based audio API. And the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre. - Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels). ...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different and very specific high-level use cases (such as creating an audio synthesizer in a webpage, or creating a video chat solution for browsers), and those rigid high-level APIs are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games. This isn't a new idea, see the Extensible Web Manifesto: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ (backup: https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto) But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).
- 5y ago

bruce343434 5y ago

Yuck. So now there's 3 of them. What's wrong with GLSL? HLSL? Somebody link that xkcd about competing standards. But seriously, why do they reinvent the wheel? Either make javascript work on the GPU (because that's the language of the web, just like C++ and Cuda go hand in hand), or just stick with HLSL.

kvark 5y ago
Apple has tried to collaborate with Microsoft on making HLSL viable for the Web and standardizing it. IIRC, we figured that we can't accept HLSL as is anyway, and we'd have to develop a flavor of it for the Web, in which case the point about using an existing language becomes moot.
rektide 5y ago
Control-flow oriented languages like JavaScript are not a good fit for GPUs. That's the accepted belief, at least. Allegedly GLSL and HLSL do not come with enough protections / guarantees for anyone to have felt comfortable porting them to the web. That rules them out cleanly. Also, these are both fairly legacy technologies, both predating Vulkan by a good bit more than a decade. WebGPU at it's core is a remake of Vulkan for the web. Then there's a shading language that works with this base. My understanding is this is a far more competent, capable means of setting up & orchestrating work, so that it can happen & flow effectively on GPUs. Doing less than WebGPU sounds supremely unappealing.

rektide 5y ago

Maybe worth noting that Deno 1.8 has WebGPU support[1]. Deno's quest to be the web-platform compatible alternative to Node is expansive & impressive!! I have high hopes for it! [1] https://deno.com/blog/v1.8 https://deno.com/blog/v1.8 https://news.ycombinator.com/item?id=26323600 https://news.ycombinator.com/item?id=26323600

Jakobeha 5y ago

Idk if WebGPU will ever be fully supported by enough browsers to be viable for the web. Even if it is eventually supported people are saying it will take 10+ years. I do think WebGPU can be a great cross-platform compute shader framework outside of the web. My experience with compute shaders is that they're really really platform specific: you need not just the right OS, but also the right graphics chip. It would be nice to write cross-platform high-end 3D apps without relying on Unity or Unreal. Also, hopefully WebGPU has better debugging tools (if they're even possible). I tried GPU programming before but it's a mess: almost every example I tried to run crashed terribly (e.g. system reboot), and even at best, I couldn't get much debugging output other than "code = problem".

rewq4321 5y ago
> people are saying it will take 10+ years Who is saying that? Genuinely curious. It has strong buy-in from Apple, Google and Mozilla, and all 3 are implementing the spec right now (and updating implementations as the spec changes). Seems very doubtful that it'd take anywhere near 10 years to be supported by major browsers. I guess it depends on what subset of graphics/compute features you need for it to be viable for your specific use case.
- Jakobeha 5y ago
  Ok, maybe not 10 years. But look at WebGL2. From wikipedia: > Development of the WebGL 2 specification started in 2013 with final in January 2017 Moreover, WebGL2 support was only added to Edge since January 2020, and as of now it's still not supported in Safari (excluding Safari TP) (from https://caniuse.com/webgl2 https://caniuse.com/webgl2).
  - rewq4321 5y ago
    I don't think you's want to use WebGL2 as an analogue here. Radically different depth and breadth of buy-in across the browser ecosystem. I'm no expert, but I'm genuinely curious where you got the 10+ year figure from (is there an up-to-date estimate/roadmap from any of the people working on this?). I was under the impression that we'd see an MVP stabilise relatively soon (i.e. within a couple of years at most). Of course, there will still be features being added in 10 years time, since graphics APIs and GPUs are always evolving.

rubatuga 5y ago

You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buffer (which required a restart), completely frozen the GPU, and can consistently trigger denial of service attacks. I can guarantee that WebGPU opens a huge attack space that is relatively unexplored.

kvark 5y ago
The current implementations are heavy WIP and incomplete. The fact that you managed to screw them up is not a big surprise. Once all of the safety and validation work is done, we'll need to check again and see.
- TonyTrapp 5y ago
  Those bugs are in the graphics drivers, not in the WebGPU implementation. Any remotely powerful GPU interface will probably be able to talk to the drivers in a way that will exploit those bugs. On the other hand, if you artificially restrict the interface so those bugs are out of reach, it will probably not be powerful enough for what it wants to be. Graphics card vendors will have to step up their game and improve their drivers.
anentropic 5y ago
It feels like this is something a "Web-" prefixed API should protect us from. I'm curious if such catastrophic behaviour is inherent to the WebGPU API as specified, or of the current implementation is failing to provide the level of safety that it should according to the spec?
- paulgb 5y ago
  > It feels like this is something a "Web-" prefixed API should protect us from. It's worth noting here that the Python wgpu library (which I'm assuming is the one GP is referring to?) is a WebGPU-inspired API to wgpu. wgpu is the library that Mozilla created as a native graphics abstraction layer to build WebGPU on top of. It's possible that Mozilla has implemented (or intends to implement) the security/validity checks between wgpu and the JavaScript interface exposed to the browser, in which case they would not automatically apply to the Python bindings.

baybal2 5y ago

The moment Google made js throttling to kill miners, miners switched to WebGL, and WASM. A WebGPU miner will be coming out the same second it is adopted.

CyberDildonics 5y ago
So what?
- baybal2 5y ago
  It is bad
  - CyberDildonics 5y ago
    Why would it be? People can do what they want. It isn't hard to avoid.
    - baybal2 5y ago
      It will be hard to avoid if it will become omnipresent
      - CyberDildonics 5y ago
        Are webGL and webasm mining "omnipresent" in web pages? What does that even mean exactly? You can turn off local storage, cookies, sound and javascript itself in per page permissions, you think every web page is going to have an unavoidable crypto currency miner embedded in it when webGPU becomes more common? Do you think that people won't be able to see that a specific iframe is using 99% of their GPU or do you think people will just live with it and won't care? I don't even think that you really believe this.

dindresto 5y ago

I took the opportunity to base my visual computing project for this semester on the Rust WebGPU implementation (wgpu-rs). Working with it is very nice, compared to OpenGL and Vulkan. The biggest pain point right now is WGSL because it still is a moving target, but it's already good enough to work with in my case. The repository for my project currently lacks any info at all unfortunately: https://github.com/niklaskorz/linon/ https://github.com/niklaskorz/linon/ It is a ray caster that I plan to evolve into a nonlinear ray caster where the viewing rays travel along a vector field which thus distorts the image. You can enable the nonlinear mode by setting the "linear_mode" constant in "src/compute.wgsl" to false. I also implemented hot reloading for the shaders, which made experimenting a lot easier. The project doesn't have any non-Rust dependencies, so giving it a go is as easy as "cargo run" in the repository directory. For an idea of what I'm aiming for, see the "Visualizing Strange Worlds" paper by Eduard Gröller from 1995: https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pdf https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pd... You can also drag&drop .obj models to load them, but I advise you to only use small models (500 triangles max) in linear mode and completely avoid it in nonlinear mode right now, as the performance is really bad at the moment. :) I'm looking into acceleration structures next, so hopefully this will improve.

Shadonototro 5y ago

--- [[stage(fragment)]] fn main() -> [[location(0)]] vec4<f32> { return vec4<f32>(0.4, 0.4, 0.8, 1.0); } --- That is very ugly and full of noise, c'mon people, that's one thing to like rust, but let's not import its ugly and noisy cluttered syntax..., it took me few seconds to understand what's going on there --- var<private> x: f32; --- let's not confuse things even more, we have vec4<f32> already, C'MON PEOPLE

kvark 5y ago
This is very similar to what you'd write in HLSL, except maybe for `[[stage(fragment)]]` part (since this information is provided externally in HLSL) and `vec4<f32>` instead of `float4`. Are these the only things you are concerned about? If so, then I'd be happy with this, given that it's an artificial example.
bschwindHN 5y ago
It's really not that bad. I had some complaints about WGSL a few months ago but it was surprising how quickly it improved. Here are some simple real-world shaders you can look at: https://github.com/bschwind/simple-game/tree/9de179085a04dd42c76bc3c39f88a54b1ba2b71f/src/graphics/shaders/wgsl https://github.com/bschwind/simple-game/tree/9de179085a04dd4... If you combine it with a quick build step to give you shader compilation errors before your program runs, it becomes a pretty nice shading language. There are still a few rough edges but it's not _that_ bad to work with.

PaulDavisThe1st 5y ago

So the long march towards the "other" future continues ... Failure #1: to get operating systems to ever agree on a truly common API for most modern computing Failure #2: to implement a write-once, run-anywhere language capable of being used for the majority of software development (mostly because the main efforts at doing so all rely on VMs that come with their own costs and benefits) Conclusion: just give up. Postulate the existence of a virtual machine inside a web browser. Spend a decade or three slowly extending the scope of that virtual machine. Put in a little bit of effort to persuade people that this new, evolving VM is the new key to "write once, run anywhere". Result: a new platform, distinct from all the rest (i.e. "native") with its own costs and benefits. Whoo-hoo.

kvark 5y ago
I very much share this concern, wrote about this semi-recently in http://kvark.github.io/web/platform/2020/09/30/platform-wars.html http://kvark.github.io/web/platform/2020/09/30/platform-wars...

eptcyka 5y ago

I fear this does nothing to prevent fingerprinting via your GPU.

boltzmann_brain 5y ago

Yes, we definitely need more shading languages.