4 ms·

> In fact it is so good I think it will replace Vulkan as well as normal OpenGL, and become just the standard way to draw, in any kind of software, from any pro

> In fact it is so good I think it will replace Vulkan as well as normal OpenGL, and become just the standard way to draw, in any kind of software, from any programming language. I fully agree with that, for a lot of use cases WebGL has everything you need, means it has the potential to become the cross platform graphics API OpenGL dreamed to be. And as a bonus you have a realistic way to run whatever app you are writing in the browser with WASM+WebGL. I just think for AAA games Vulcan, Metal and DirectX12 will probably still be the way to go. But GUI libraries? Less highest end games? There is just no point once you can use WebGL everywhere. And then if you want to have a browser Demo you have a realistic chance to get it.

karussell 4y ago
> for a lot of use cases WebGL has everything you need I think the original post refers to WebGPU
- JayStavis 4y ago
  I can't tell if it's just a masterful troll implying web graphics history repeats itself.
  - dathinab 4y ago
    it's a very embarrassing typo. given that WebGL was known to use an "old" approach even before it was released and we don't have the problem with WebGPU I hope history doesn't repeats itself
    - pjmlp 4y ago
      History is repeating itself, there is no roadmap for mesh shaders or ray tracing.
api 4y ago
So wait... do we now have a situation where the browser engine has converged with where the Java Virtual Machine was and provided a container to run write-once-run-anywhere desktop apps compiled to WASM? All we need is the last mile -- progressive web apps -- to include better support for integration with desktop OSes and we have a way to take WASM apps and drag them to the desktop. The up and coming languages for writing these WASM apps seem to be Go and Rust. Here's a Rust example: https://www.egui.rs https://www.egui.rs
- flohofwoe 4y ago
  WebGPU can be used outside of the browser through native libraries: https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn (these are the libraries that are used in Firefox and Chrome to provide the WebGPU implementation, don't know if Apple/WebKit also has open-sourced theirs) Some non-browser WASM runtimes also have WebGPU support already, but unfortunately only for offscreen rendering or compute tasks (e.g. for writing cross-platform windowed apps as WASM blobs, there's a window system glue layer missing).
  - Jasper_ 4y ago
    > don't know if Apple/WebKit also has open-sourced theirs https://github.com/WebKit/WebKit/tree/main/Source/WebGPU https://github.com/WebKit/WebKit/tree/main/Source/WebGPU
wffurr 4y ago
I don’t know about WebGPU, but WebGL is missing some key performance features from OpenGL ES, like client-side buffers, pixel buffer objects, and MSAA render-to-texture frame buffers.
- Jasper_ 4y ago
  Client-side buffers are not a great idea. Pixel buffer objects and MSAA framebuffers exist in WebGL 2.
  - wffurr 4y ago
    WebGL MSAA framebuffers exist, but require extra memory and an intermediate step compared to EXT_multisampled_render_to_texture https://registry.khronos.org/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt https://registry.khronos.org/OpenGL/extensions/EXT/EXT_multi... PBO support in WebGL lacks glMapBufferRange for non blocking read back.
sva_ 4y ago
Too bad that WebGPU builds on top of Vulkan, so the dependency (and incomplete support for some configurations) is still there.
- jsheard 4y ago
  WebGPU is designed to split the difference between Vulkan, DirectX 12 and Metal, it can be implemented on top of any of those. In practice it'll only use Vulkan on Android and Linux, the main two implementations both default to DX12 on Windows even though they could technically use Vulkan there.
  - CryZe 4y ago
    wgpu at least prefers Vulkan over DirectX 12 on Windows.
    - jsheard 4y ago
      My mistake, they plan to use DX12 by default on Windows, but the DX12 backend isn't fully cooked yet so for now it defaults to Vulkan. https://github.com/gfx-rs/wgpu/issues/2719 https://github.com/gfx-rs/wgpu/issues/2719

karussell 4y ago

> for a lot of use cases WebGL has everything you need I think the original post refers to WebGPU

JayStavis 4y ago
I can't tell if it's just a masterful troll implying web graphics history repeats itself.
- dathinab 4y ago
  it's a very embarrassing typo. given that WebGL was known to use an "old" approach even before it was released and we don't have the problem with WebGPU I hope history doesn't repeats itself
  - pjmlp 4y ago
    History is repeating itself, there is no roadmap for mesh shaders or ray tracing.

api 4y ago

So wait... do we now have a situation where the browser engine has converged with where the Java Virtual Machine was and provided a container to run write-once-run-anywhere desktop apps compiled to WASM? All we need is the last mile -- progressive web apps -- to include better support for integration with desktop OSes and we have a way to take WASM apps and drag them to the desktop. The up and coming languages for writing these WASM apps seem to be Go and Rust. Here's a Rust example: https://www.egui.rs https://www.egui.rs

flohofwoe 4y ago
WebGPU can be used outside of the browser through native libraries: https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn (these are the libraries that are used in Firefox and Chrome to provide the WebGPU implementation, don't know if Apple/WebKit also has open-sourced theirs) Some non-browser WASM runtimes also have WebGPU support already, but unfortunately only for offscreen rendering or compute tasks (e.g. for writing cross-platform windowed apps as WASM blobs, there's a window system glue layer missing).
- Jasper_ 4y ago
  > don't know if Apple/WebKit also has open-sourced theirs https://github.com/WebKit/WebKit/tree/main/Source/WebGPU https://github.com/WebKit/WebKit/tree/main/Source/WebGPU

wffurr 4y ago

I don’t know about WebGPU, but WebGL is missing some key performance features from OpenGL ES, like client-side buffers, pixel buffer objects, and MSAA render-to-texture frame buffers.

Jasper_ 4y ago
Client-side buffers are not a great idea. Pixel buffer objects and MSAA framebuffers exist in WebGL 2.
- wffurr 4y ago
  WebGL MSAA framebuffers exist, but require extra memory and an intermediate step compared to EXT_multisampled_render_to_texture https://registry.khronos.org/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt https://registry.khronos.org/OpenGL/extensions/EXT/EXT_multi... PBO support in WebGL lacks glMapBufferRange for non blocking read back.

sva_ 4y ago

Too bad that WebGPU builds on top of Vulkan, so the dependency (and incomplete support for some configurations) is still there.

jsheard 4y ago
WebGPU is designed to split the difference between Vulkan, DirectX 12 and Metal, it can be implemented on top of any of those. In practice it'll only use Vulkan on Android and Linux, the main two implementations both default to DX12 on Windows even though they could technically use Vulkan there.
- CryZe 4y ago
  wgpu at least prefers Vulkan over DirectX 12 on Windows.
  - jsheard 4y ago
    My mistake, they plan to use DX12 by default on Windows, but the DX12 backend isn't fully cooked yet so for now it defaults to Vulkan. https://github.com/gfx-rs/wgpu/issues/2719 https://github.com/gfx-rs/wgpu/issues/2719