5 ms·

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 th

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.
haxiomic 5y ago
From the start WebGPU has been build with native use in mind, so ideally you'd just target WebGPU for both your web and native builds. The WebGPU native implementation can then drive the native graphics API for your system (and one day perhaps we'll see WebGPU at the driver level)
- slmjkdbtl 5y ago
  > build with native use in mind Do you mean they're thinking "this can easily be translated to other graphic interfaces" or "we're going to convince vendors to ship products with WebGPU driver built-in like OpenGL"? I'll be so happy to see WebGPU on driver level, but can't find evidence on if anyone is interested in providing.
  - gmueckl 5y ago
    Expect having to ship a WebGPU implementation with your application, similar to how you need to include ANGLE for WebGL support. A platform level API needs a lot of additional considerations about plumbing layers between applications and one or more separately installed drivers. I don't see this addressed for WebGPU.
gmueckl 5y ago
The irony is that with OpenGL and WwbGL getting left behind, graphics programming becomes a bit more uniform across platforms as a result, even though the underlying APIs are different. They are based on very similar modern concepts. OpenGL on the other hand really shows its age and isn't a good fit anymore. Some newer things have been bolted on awkwardly over time, but they are either optional extensions or part of versions that are newer than what certain target platforms actually support. Looking at the various rendering backends for our product, the OpenGL backend is the most byzantine one. The Vulkan backend has more code, but all of that is fairly sane. It doesn't have accidental complexity like having to pick the right GL function to upload a specific texture out of about a dozen possibilities depending on the texture type and target OpenGL version/extensions.
- pjmlp 5y ago
  Right, https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php
  - gmueckl 5y ago
    Believe it or not, this stuff is (still?) fairly sane compared to OpenGL in reality.
    - pjmlp 5y ago
      I don't, given that I did my thesis in porting a particle system from NeXTSTEP to Windows in OpenGL back in 1999, and am relatively confortable with Khronos APIs. The only thing that saves Vulkan is that it isn't as old as OpenGL, with a similar timeframe it will get just as bad, or even worse given its complexity for the average graphics programmer that doesn't hold a master on GPGPU hardware design to understand the nuances of all those extensions.
nightowl_games 5y ago
How is Vulkan vendor specific? How will WebGPU be more cross platform than Vulkan? (MoltenVK works very well)

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.

haxiomic 5y ago

From the start WebGPU has been build with native use in mind, so ideally you'd just target WebGPU for both your web and native builds. The WebGPU native implementation can then drive the native graphics API for your system (and one day perhaps we'll see WebGPU at the driver level)

slmjkdbtl 5y ago
> build with native use in mind Do you mean they're thinking "this can easily be translated to other graphic interfaces" or "we're going to convince vendors to ship products with WebGPU driver built-in like OpenGL"? I'll be so happy to see WebGPU on driver level, but can't find evidence on if anyone is interested in providing.
- gmueckl 5y ago
  Expect having to ship a WebGPU implementation with your application, similar to how you need to include ANGLE for WebGL support. A platform level API needs a lot of additional considerations about plumbing layers between applications and one or more separately installed drivers. I don't see this addressed for WebGPU.

gmueckl 5y ago

The irony is that with OpenGL and WwbGL getting left behind, graphics programming becomes a bit more uniform across platforms as a result, even though the underlying APIs are different. They are based on very similar modern concepts. OpenGL on the other hand really shows its age and isn't a good fit anymore. Some newer things have been bolted on awkwardly over time, but they are either optional extensions or part of versions that are newer than what certain target platforms actually support. Looking at the various rendering backends for our product, the OpenGL backend is the most byzantine one. The Vulkan backend has more code, but all of that is fairly sane. It doesn't have accidental complexity like having to pick the right GL function to upload a specific texture out of about a dozen possibilities depending on the texture type and target OpenGL version/extensions.

pjmlp 5y ago
Right, https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php
- gmueckl 5y ago
  Believe it or not, this stuff is (still?) fairly sane compared to OpenGL in reality.
  - pjmlp 5y ago
    I don't, given that I did my thesis in porting a particle system from NeXTSTEP to Windows in OpenGL back in 1999, and am relatively confortable with Khronos APIs. The only thing that saves Vulkan is that it isn't as old as OpenGL, with a similar timeframe it will get just as bad, or even worse given its complexity for the average graphics programmer that doesn't hold a master on GPGPU hardware design to understand the nuances of all those extensions.

nightowl_games 5y ago

How is Vulkan vendor specific? How will WebGPU be more cross platform than Vulkan? (MoltenVK works very well)