3 ms·

> 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 Th

by 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.
        wtetzner 5y ago
        I understand your point, but I don’t think there’s any value in including an extra layer of abstraction before you need it. Sometimes it’s clear that you need it from the start. But sometimes it’s not. And if you end up needing to support something sufficiently different from what can fit into wgpu’s API, the right point of indirection might just be the rendering system. E.g., you might just write a separate renderer for the new platform, so you can write to its model in the most efficient way.

by kvark 5y ago

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.
      - wtetzner 5y ago
        I understand your point, but I don’t think there’s any value in including an extra layer of abstraction before you need it. Sometimes it’s clear that you need it from the start. But sometimes it’s not. And if you end up needing to support something sufficiently different from what can fit into wgpu’s API, the right point of indirection might just be the rendering system. E.g., you might just write a separate renderer for the new platform, so you can write to its model in the most efficient way.