3 ms·

I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bi

by twic 7y ago

I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bindings. Here's what i think: 1. Vulkan is an API for doing graphics which is modern and standard 2. Direct3D (part of DirectX, the names are sometimes used interchangeably), Metal, and OpenGL are APIs for doing graphics which are modern or standard 3. Vulkan, Direct3D, Metal, and OpenGL are all implemented by graphics card drivers and operating systems working together - this is pretty much the bottom of the software stack 4. gfx-hal (along with gfx-backend-*) is a Rust library which abstracts over Vulkan, Direct3D, Metal, and OpenGL; its API is similar to Vulkan, but not identical 5. The Vulkan portability bindings implement Vulkan (the "universally portable subset") on top of gfx-hal (to an extent - it seems like there are lots of little bits that can't be implemented for each backend) 6. WebGPU is an API for doing graphics which is modern, standard, and easier than Vulkan 7. WebGPU is (or soon will be) implemented directly by browers, on top of who knows what, Direct3D etc i suppose 8. wgpu-core is an implementation of (a Rust projection of) WebGPU on top of gfx-hal 9. wgpu-native is a C API on top of wgpu-core 10. wgpu-rs is a nice Rust API on top of WebGPU, which can (now!) use either a browser's WebGPU, or wgpu-native gfx-rs is the name of the overall project. I'm sticking to text mode.

DagAgren 7y ago
1. Vulkan, Direct3D, Metal, and OpenGL are all native 3D APIs on different platforms. 2. WebGPU is a new 3D API, designed to be used in browsers (but not limited to them) and implemented on top of one or more of the native APIs. 3. wgpu-native is Mozilla's implementation of WebGPU, built in Rust on top of gfx-hal, which is a Rust-specific abstraction on top of native APIs. 3. wgpu-rs is a convenience wrapper to make the API more Rust-like, which either uses wgpu-native directly, or when compiled for a browser, the browser's own WebGPU implementation. 4. Dawn is Google's implementation of WebGPU, in C++, which similarly can be used directly or through a browser.
- DagAgren 7y ago
  The nice side effect here is that even if you are not targeting browsers, if you want a modern, fast, usable and cross-platform 3D API, there now is one, which hasn't been the case for a long time. And there are at least two different implementations of it.
kvark 7y ago
I drew this on the whiteboard within Mozilla a few times, and I agree it would be nice to make it more accessible and hosted at gfx-rs repository or the blog. There is a few scattered sub-diagrams on the topic, buried in the various slide decks I made: https://github.com/kvark/slides/blob/master/BuildingWebGPUwithRust_Fosdem2020.pdf https://github.com/kvark/slides/blob/master/BuildingWebGPUwi... https://github.com/kvark/slides/blob/master/IntroductionToWebGPU_BerlinAllHands.pdf https://github.com/kvark/slides/blob/master/IntroductionToWe... https://github.com/kvark/slides/blob/master/VkPI-WebGPU.pdf https://github.com/kvark/slides/blob/master/VkPI-WebGPU.pdf
- rl3 7y ago
  I like the diagram that has "Google's Dawn" and "Apple's something" side by side. :) Thanks for all your hard work on gfx-rs! I've been following its progress for a few years now, and despite the major architecture redesign, the project appears to be stronger than ever now. Bravo. Your work is much appreciated.
MrBuddyCasino 7y ago
So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs Anyone has an idea how much performance those layers of abstraction cost?
- kvark 7y ago
  It's really hard to estimate without implementing alternative paths that are more direct and yet fairly optimized. For example, since Intel and AMD have open-source drivers on Linux, somebody could write respective wgpu-core implementations directly on top of the drivers. That's a lot of work, and without a clear prospect of being much faster.
- grovesNL 7y ago
  Both wgpu and gfx APIs try to avoid any significant CPU usage in hot rendering/compute paths (e.g. by doing more work upfront instead of during rendering), so generally the performance cost should be fairly low for most applications. The Vulkan API is basically 1:1 with gfx-hal so the performance cost should be negligible when gfx-hal is running on top of Vulkan. There is some overhead when running on top of other backends (such as Metal or DX12) versus implementing separate backends for wgpu, but the design of WebGPU avoids most places where the overhead would become significant anyway. Similarly wgpu-rs only adds Rustier bindings to wgpu-core, so any performance cost should be negligible. There is some amount of overhead in WebGPU in general (caused by automatic memory management, additional resource tracking, etc.) versus directly using raw Vulkan/DX12/Metal, but WebGPU tries to find a good balance here between security/portability/performance/usability.

by twic 7y ago

DagAgren 7y ago

1. Vulkan, Direct3D, Metal, and OpenGL are all native 3D APIs on different platforms. 2. WebGPU is a new 3D API, designed to be used in browsers (but not limited to them) and implemented on top of one or more of the native APIs. 3. wgpu-native is Mozilla's implementation of WebGPU, built in Rust on top of gfx-hal, which is a Rust-specific abstraction on top of native APIs. 3. wgpu-rs is a convenience wrapper to make the API more Rust-like, which either uses wgpu-native directly, or when compiled for a browser, the browser's own WebGPU implementation. 4. Dawn is Google's implementation of WebGPU, in C++, which similarly can be used directly or through a browser.

DagAgren 7y ago
The nice side effect here is that even if you are not targeting browsers, if you want a modern, fast, usable and cross-platform 3D API, there now is one, which hasn't been the case for a long time. And there are at least two different implementations of it.

kvark 7y ago

I drew this on the whiteboard within Mozilla a few times, and I agree it would be nice to make it more accessible and hosted at gfx-rs repository or the blog. There is a few scattered sub-diagrams on the topic, buried in the various slide decks I made: https://github.com/kvark/slides/blob/master/BuildingWebGPUwithRust_Fosdem2020.pdf https://github.com/kvark/slides/blob/master/BuildingWebGPUwi... https://github.com/kvark/slides/blob/master/IntroductionToWebGPU_BerlinAllHands.pdf https://github.com/kvark/slides/blob/master/IntroductionToWe... https://github.com/kvark/slides/blob/master/VkPI-WebGPU.pdf https://github.com/kvark/slides/blob/master/VkPI-WebGPU.pdf

rl3 7y ago
I like the diagram that has "Google's Dawn" and "Apple's something" side by side. :) Thanks for all your hard work on gfx-rs! I've been following its progress for a few years now, and despite the major architecture redesign, the project appears to be stronger than ever now. Bravo. Your work is much appreciated.

MrBuddyCasino 7y ago

So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs Anyone has an idea how much performance those layers of abstraction cost?

kvark 7y ago
It's really hard to estimate without implementing alternative paths that are more direct and yet fairly optimized. For example, since Intel and AMD have open-source drivers on Linux, somebody could write respective wgpu-core implementations directly on top of the drivers. That's a lot of work, and without a clear prospect of being much faster.
grovesNL 7y ago
Both wgpu and gfx APIs try to avoid any significant CPU usage in hot rendering/compute paths (e.g. by doing more work upfront instead of during rendering), so generally the performance cost should be fairly low for most applications. The Vulkan API is basically 1:1 with gfx-hal so the performance cost should be negligible when gfx-hal is running on top of Vulkan. There is some overhead when running on top of other backends (such as Metal or DX12) versus implementing separate backends for wgpu, but the design of WebGPU avoids most places where the overhead would become significant anyway. Similarly wgpu-rs only adds Rustier bindings to wgpu-core, so any performance cost should be negligible. There is some amount of overhead in WebGPU in general (caused by automatic memory management, additional resource tracking, etc.) versus directly using raw Vulkan/DX12/Metal, but WebGPU tries to find a good balance here between security/portability/performance/usability.