5 ms·

Why not use webgpu?

diggan 3y ago
At a glance, IGL (this submission) seems more similar to wgpu than WebGPU. But then the question just becomes "Why not use wgpu?" instead.
foota 3y ago
I'm guessing it predates webgpu internally.
swatcoder 3y ago
Because projects have all sorts of requirements. Shipping and running an embedded browser engine, or running in a user's active browser session, is not going to fit the requirements for many many projects.
- sluijs 3y ago
  WebGPU is - despite the name - not designed to run in a browser per se. You can use wgpu and Dawn as native crates/libraries as well.
MegaDeKay 3y ago
They gives these reasons at the Github link for its existence... --- Intermediate Graphics Library (IGL) is a cross-platform library that commands the GPU. It encapsulates common GPU functionality with a low-level cross-platform interface. IGL is designed to support multiple backends implemented on top of various graphics APIs (e.g. OpenGL, Metal and Vulkan) with a common interface. There are a lot of good options for abstracting GPU API's; each making different trade-offs. We designed IGL around the following priorities: - Low-level, forward-looking API. IGL embraces modern abstractions (command buffers, state containers, bindless, etc) and is designed to give more control than OpenGL's state machine API. As a result, IGL can have leaner backends for modern API's (e.g. Metal, Vulkan). - Minimal overhead for C++. IGL supports new or existing native rendering code without overhead of language interop or the need for other language runtimes. - Reach + scale in production. IGL has been globally battle-tested for broad device reliability (especially the long-tail of Android devices as well as Quest 2/3/Pro compatibility for OpenGL/Vulkan) and performance-tuned on our apps.
- skavi 3y ago
  The first two points easily apply to WebGPU. Maybe not the last one yet.
- bmitc 3y ago
  Having researched WebGPU a little, I'm not seeing anything there that explains why this over WebGPU. As far as I understand, those reasons are identical to those for WebGPU. Can anyone explain?
  - jayd16 3y ago
    Is Android support solid for Dawn/webgpu? Seems like it's marked as work in progress compared to the confident support laid out here.
    - adamnemecek 3y ago
      Right but if they needed that, they could have just contributed android support to wgpu.
  - swatcoder 3y ago
    Meta has bet the farm on their VR/AR/XR platform and smartly wants control over the tooling that developers will use to target it. The last thing they want is for some Quest innovation to be hamstrung waiting for a standard body to approve support for some new feature or for a third-party open source maintainer to incorporate some fix/addition/compatibility PR. Owning a project like this, if they can get developers to use it, is a huge business security asset and competitive advantage for them. That's why this exists and why it's being promoted. Whether developers see it as worth using instead of other options is a different question. Meta would probably say the answer to "why" for developers is: "to make sure your project gets the most out of the Quest products (as well as other Android platforms), now and in the future"
    - adamnemecek 3y ago
      They can’t get users to use it as it provides little over webgpu.
rossant 3y ago
Yes, it is weird that WebGPU is not even mentioned on the README. Maybe this project was initiated before WebGPU was mature enough (for the record, WebGPU is still mentioned as an "experimental technology" by MDN (https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API).

Why not use webgpu?

At a glance, IGL (this submission) seems more similar to wgpu than WebGPU. But then the question just becomes "Why not use wgpu?" instead.

foota 3y ago

I'm guessing it predates webgpu internally.

swatcoder 3y ago

Because projects have all sorts of requirements. Shipping and running an embedded browser engine, or running in a user's active browser session, is not going to fit the requirements for many many projects.

sluijs 3y ago
WebGPU is - despite the name - not designed to run in a browser per se. You can use wgpu and Dawn as native crates/libraries as well.

MegaDeKay 3y ago

They gives these reasons at the Github link for its existence... --- Intermediate Graphics Library (IGL) is a cross-platform library that commands the GPU. It encapsulates common GPU functionality with a low-level cross-platform interface. IGL is designed to support multiple backends implemented on top of various graphics APIs (e.g. OpenGL, Metal and Vulkan) with a common interface. There are a lot of good options for abstracting GPU API's; each making different trade-offs. We designed IGL around the following priorities: - Low-level, forward-looking API. IGL embraces modern abstractions (command buffers, state containers, bindless, etc) and is designed to give more control than OpenGL's state machine API. As a result, IGL can have leaner backends for modern API's (e.g. Metal, Vulkan). - Minimal overhead for C++. IGL supports new or existing native rendering code without overhead of language interop or the need for other language runtimes. - Reach + scale in production. IGL has been globally battle-tested for broad device reliability (especially the long-tail of Android devices as well as Quest 2/3/Pro compatibility for OpenGL/Vulkan) and performance-tuned on our apps.

skavi 3y ago
The first two points easily apply to WebGPU. Maybe not the last one yet.
bmitc 3y ago
Having researched WebGPU a little, I'm not seeing anything there that explains why this over WebGPU. As far as I understand, those reasons are identical to those for WebGPU. Can anyone explain?
- jayd16 3y ago
  Is Android support solid for Dawn/webgpu? Seems like it's marked as work in progress compared to the confident support laid out here.
  - adamnemecek 3y ago
    Right but if they needed that, they could have just contributed android support to wgpu.
- swatcoder 3y ago
  Meta has bet the farm on their VR/AR/XR platform and smartly wants control over the tooling that developers will use to target it. The last thing they want is for some Quest innovation to be hamstrung waiting for a standard body to approve support for some new feature or for a third-party open source maintainer to incorporate some fix/addition/compatibility PR. Owning a project like this, if they can get developers to use it, is a huge business security asset and competitive advantage for them. That's why this exists and why it's being promoted. Whether developers see it as worth using instead of other options is a different question. Meta would probably say the answer to "why" for developers is: "to make sure your project gets the most out of the Quest products (as well as other Android platforms), now and in the future"
  - adamnemecek 3y ago
    They can’t get users to use it as it provides little over webgpu.

rossant 3y ago

Yes, it is weird that WebGPU is not even mentioned on the README. Maybe this project was initiated before WebGPU was mature enough (for the record, WebGPU is still mentioned as an "experimental technology" by MDN (https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API).