8 ms·

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform

A situation will inevitably arise where you’ll be unable to support a new platform in a reasonable amount of time because implementing support for that platform yourself in wgpu would be a significant undertaking and/or distraction. Progress from the community on supporting that platform in wgpu will lag because either you might be the only stakeholder interested in that platform and/or modifying wgpu to support that platform may require significant internal restructuring to support the platform in a non-hacky way or it would slow down or increase the complexity of the other main platforms. This is a hypothetical situation but it’s likely it will eventually happen. Maintaining a fork of wgpu simply for your own project will also likely be more effort than necessary since wgpu is a more general API than bevy requires. The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain. Some call this “the rule of least power” https://www.w3.org/2001/tag/doc/leastPower.html https://www.w3.org/2001/tag/doc/leastPower.html The meta-core issue is that you and the wgpu team aren’t 100% aligned on your goals. Maybe you’re aligned on 80% but the 20% will eventually come back to haunt you.

kvark 5y ago
> The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Generally speaking, depending on another library always involve some amount of trust. Going the path of zero trust is also possible, but is much less effective.
- CyberRabbi 5y ago
  > This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Small is not the issue. Generality is.
  - Jweb_Guru 5y ago
    Keep in mind that wgpu is intended to be something you can write a game engine in and achieve at least comparable performance to going through something like Vulkan directly. The WebGPU API is intended to be optimizable enough that even low-level applications don't need to reach for their own solutions, and the WebGPU team have worked very hard to find universal and efficient abstractions over the underlying drivers. It also provides unsafe opt-out functionality for cases where the goal of safety clashes too much with the performance needs of some applications (such as using precompiled shaders). Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine? Many of the features you're probably thinking of are a nonstarter if you want to be cross-platform, and being efficient cross-platform is a key motivating reason to use wgpu in the first place.
    - CyberRabbi 5y ago
      > Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine? My concern isn’t that wgpu’s level of generality makes it unsuitable for implementing a game engine. It’s of course perfectly suitable for implementing a game engine. The concern is around the pitfalls of not architecting your game engine in terms of your own limited graphics abstraction (which may backend to wgpu).
      - nindalf 5y ago
        You’ve made like 15 comments on this thread with this idea. Cart is intent on sticking to his approach even after listening to your point of view. I feel like we could just put this conversation on ice and check back in after 6-12 months. Bevy release notes always reach the top of HN. If they go back to creating an abstraction over wgpu, you can say “I told you so” then. And similarly, if Bevy is able to use this approach to provide support for Android, iOS and web (in addition to existing support for windows, Linux and Mac) then you need to own up to that.
        CyberRabbi 5y ago
        > You’ve made like 15 comments on this thread with this idea. Yet other people beside Cart in my thread still fail to properly understand the idea and instead think I am suggesting not using wgpu at all. > you can say “I told you so” then My aim isn’t to say “I told you so” it’s to make sure people accurately understand the point I am making. Cart seems to understand the point I am making therefore I have made no further comments to him.
Jasper_ 5y ago
As someone who's developed and maintained platform backends for all sorts of obscure platforms (actually, it's still my day job!), I don't think wgpu backends are going to be difficult to develop for any of the remaining platforms APIs still alive. It's a pretty well-thought-out API that mirrors most of the modern rendering abstractions seen in game engines.
- CyberRabbi 5y ago
  > platforms APIs still alive. The APIs that currently exist are not the cause of the potential issue I am raising.
  - epage 5y ago
    And without knowing what those future APIs are like, you can't design a future-proof backend API to handle it. You'll design it for the past problems which will be different than future ones.
    - CyberRabbi 5y ago
      What you can do is design a backend for your project that is less general and tailored to your specific problems so as to increase the likelihood that it is easier to implement on new platforms that may arise. This is why I mentioned the “rule of least power” For example using drawTriangle(p1, p2, p3) instead of drawPolys(TYPE_TRIANGLE, point_list, n_points). The former is unequivocally easier to implement, the latter requires more complexity.
      - dralley 5y ago
        And it has been explained to you repeatedly that wgpu is already more or less "least power" - that Bevy already uses most of the API surface and will soon be using nearly all of it.
        CyberRabbi 5y ago
_cart 5y ago
Adding new "backends" to an abstraction always includes the risk of not being compatible with the current abstraction and requiring re-architectures. This would be true with our own abstractions as well. I agree that two separate projects often have different goals, but wgpu's goals are an (almost) complete subset of our goals: cross platform modern gpu layer that cleanly abstracts Vulkan/Metal/DX12 and best-effort abstracts older apis, rust-friendly api surface with RAII, limited "lowest common denominator" defaults that run everywhere with opt-in support for advanced features and lifting lowest-common-denominator limits. The biggest divergence is their increased need for safety features to make wgpu a suitable host for WebGPU apis in browsers, but this is something that still benefits us, because it might ultimately allow Bevy apps to "host" less trusted shader code. We've been building out the new renderer and we have already used a huge percentage of wgpu's api surface. It will be close to 100% by the time we launch. This proves to me that we do need almost all of the features they provide. Bevy's renderer is modular and we need to expose a generic (and safe) gpu api to empower users to build new render features. Wgpu's entire purpose is to be that API. I know enough of the details here (because I built my own api, thoroughly reviewed the wgpu code, and did the same for alternatives in the ecosystem) to feel comfortable betting on it. I'm even more comfortable having reviewed bevy-user-provided wgpu prs that add major new features to wgpu (XR). If you have specific concerns about specific features, I'm happy to discuss this further. You can link to as many "rules" as you want, but solving a problem in the real world requires a careful balance of many variables and concerns. Rules like "the rule of least power" should be a guiding principle, not something to be followed at all costs.
- gfxgirl 5y ago
  I think wgpu is amazing. But, if I want to take the previous commenter seriously I'd think about PS5, Switch/Switch2, etc as places where someone will have to write a wgpu implementation (non open source since those SDKs don't allow it) if you ever decide to ship on those platforms.
  - Jweb_Guru 5y ago
    wgpu's recent license change was specifically done to allow these implementations to exist for consoles.

kvark 5y ago

> The core issue is that bevy uses a subset of wgpu so your own focused and limited abstraction layer will almost always be easier to implement and maintain This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Generally speaking, depending on another library always involve some amount of trust. Going the path of zero trust is also possible, but is much less effective.

CyberRabbi 5y ago
> This isn't obviously true. WebGPU API surface is fairly small (unlike Vulkan), and Bevy may easily use most of it. Small is not the issue. Generality is.
- Jweb_Guru 5y ago
  Keep in mind that wgpu is intended to be something you can write a game engine in and achieve at least comparable performance to going through something like Vulkan directly. The WebGPU API is intended to be optimizable enough that even low-level applications don't need to reach for their own solutions, and the WebGPU team have worked very hard to find universal and efficient abstractions over the underlying drivers. It also provides unsafe opt-out functionality for cases where the goal of safety clashes too much with the performance needs of some applications (such as using precompiled shaders). Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine? Many of the features you're probably thinking of are a nonstarter if you want to be cross-platform, and being efficient cross-platform is a key motivating reason to use wgpu in the first place.
  - CyberRabbi 5y ago
    > Given all this, what do you think is missing that makes it "too general" for use as the basis of a game engine? My concern isn’t that wgpu’s level of generality makes it unsuitable for implementing a game engine. It’s of course perfectly suitable for implementing a game engine. The concern is around the pitfalls of not architecting your game engine in terms of your own limited graphics abstraction (which may backend to wgpu).
    - nindalf 5y ago
      You’ve made like 15 comments on this thread with this idea. Cart is intent on sticking to his approach even after listening to your point of view. I feel like we could just put this conversation on ice and check back in after 6-12 months. Bevy release notes always reach the top of HN. If they go back to creating an abstraction over wgpu, you can say “I told you so” then. And similarly, if Bevy is able to use this approach to provide support for Android, iOS and web (in addition to existing support for windows, Linux and Mac) then you need to own up to that.
      - CyberRabbi 5y ago
        > You’ve made like 15 comments on this thread with this idea. Yet other people beside Cart in my thread still fail to properly understand the idea and instead think I am suggesting not using wgpu at all. > you can say “I told you so” then My aim isn’t to say “I told you so” it’s to make sure people accurately understand the point I am making. Cart seems to understand the point I am making therefore I have made no further comments to him.

Jasper_ 5y ago

As someone who's developed and maintained platform backends for all sorts of obscure platforms (actually, it's still my day job!), I don't think wgpu backends are going to be difficult to develop for any of the remaining platforms APIs still alive. It's a pretty well-thought-out API that mirrors most of the modern rendering abstractions seen in game engines.

CyberRabbi 5y ago
> platforms APIs still alive. The APIs that currently exist are not the cause of the potential issue I am raising.
- epage 5y ago
  And without knowing what those future APIs are like, you can't design a future-proof backend API to handle it. You'll design it for the past problems which will be different than future ones.
  - CyberRabbi 5y ago
    What you can do is design a backend for your project that is less general and tailored to your specific problems so as to increase the likelihood that it is easier to implement on new platforms that may arise. This is why I mentioned the “rule of least power” For example using drawTriangle(p1, p2, p3) instead of drawPolys(TYPE_TRIANGLE, point_list, n_points). The former is unequivocally easier to implement, the latter requires more complexity.
    - dralley 5y ago
      And it has been explained to you repeatedly that wgpu is already more or less "least power" - that Bevy already uses most of the API surface and will soon be using nearly all of it.
      - CyberRabbi 5y ago

_cart 5y ago

Adding new "backends" to an abstraction always includes the risk of not being compatible with the current abstraction and requiring re-architectures. This would be true with our own abstractions as well. I agree that two separate projects often have different goals, but wgpu's goals are an (almost) complete subset of our goals: cross platform modern gpu layer that cleanly abstracts Vulkan/Metal/DX12 and best-effort abstracts older apis, rust-friendly api surface with RAII, limited "lowest common denominator" defaults that run everywhere with opt-in support for advanced features and lifting lowest-common-denominator limits. The biggest divergence is their increased need for safety features to make wgpu a suitable host for WebGPU apis in browsers, but this is something that still benefits us, because it might ultimately allow Bevy apps to "host" less trusted shader code. We've been building out the new renderer and we have already used a huge percentage of wgpu's api surface. It will be close to 100% by the time we launch. This proves to me that we do need almost all of the features they provide. Bevy's renderer is modular and we need to expose a generic (and safe) gpu api to empower users to build new render features. Wgpu's entire purpose is to be that API. I know enough of the details here (because I built my own api, thoroughly reviewed the wgpu code, and did the same for alternatives in the ecosystem) to feel comfortable betting on it. I'm even more comfortable having reviewed bevy-user-provided wgpu prs that add major new features to wgpu (XR). If you have specific concerns about specific features, I'm happy to discuss this further. You can link to as many "rules" as you want, but solving a problem in the real world requires a careful balance of many variables and concerns. Rules like "the rule of least power" should be a guiding principle, not something to be followed at all costs.

gfxgirl 5y ago
I think wgpu is amazing. But, if I want to take the previous commenter seriously I'd think about PS5, Switch/Switch2, etc as places where someone will have to write a wgpu implementation (non open source since those SDKs don't allow it) if you ever decide to ship on those platforms.
- Jweb_Guru 5y ago
  wgpu's recent license change was specifically done to allow these implementations to exist for consoles.