Create 2019-09-02-feature-less.md #32
Conversation
A draft for the feature-less update
|
This is something I wanted to share with the community and drafted quickly. Questions not resolved yet, I'd appreciate your opinion on:
|
|
I'd put it somewhere and then link it into the gamedev-wg newsletter |
| --- | ||
| layout: post | ||
| title: ??? | ||
| --- |
There was a problem hiding this comment.
Maybe we could call it gfx and wgpu summer 2019 highlights or similar, which would be a good place to mention usage in new crates. We don't have to commit to seasonal highlights but it might be useful to have check-ins every once in a while anyway.
| --- | ||
| layout: post | ||
| title: ??? | ||
| --- |
There was a problem hiding this comment.
It would be good to have the gfx and wgpu introductions here too (for new readers)
There was a problem hiding this comment.
Yeah, I bet 99% of people outside the hardcore rust graphics dev community don't know how wgpu and gfx-hal are related
|
|
||
| With the set of supported backends growing, this became more and more of an issue. Asking the user to enable the proper feature doesn't solve the problem - it just puts it on the users shoulders. Moreover, using features in such a way is typically non-idiomatic, because in Rust features are supposed to be additive, but most of the user code was written to work with a single backend, even if it's generic. | ||
|
|
||
| Today, we are happy to announce that the problem is solved in wgpu-rs! Features are gone. The library knows which backends are supported on the target platform, it checks for their availability and enumerates their phusical adapters. When the user requests an adapter, they can provide a mask of backends, and the implementation will pick the most suitable adapter on one of the enabled backends. |
|
|
||
| ## Slimmed gfx-rs | ||
|
|
||
| We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the gfx-hal build by a factor of 8.5X. |
There was a problem hiding this comment.
We've done -> We've taken
| ## Slimmed gfx-rs | ||
|
|
||
| We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the gfx-hal build by a factor of 8.5X. | ||
|
|
There was a problem hiding this comment.
I'd probably split "First of all..." to a new paragraph to start the list of steps to match the level of "Secondly"
| We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the gfx-hal build by a factor of 8.5X. | ||
|
|
||
| Secondly, the "typed" layer of gfx-hal got removed. Previously, we recognized that the view of the API for the backends (when implementing it) needs to be different from the users (to use it). Backends just need to implement "raw" interfaces, while users need more type safety, such as limiting the set of operations available on a command buffer when recording a render pass. This duality of APIs in gfx-hal worked to an extent. Providing safety was impossible without imposing some restrictions or overhead. At the end of the day, we decided that the "typed" (user-facing) layer is still useful, but it doesn't have to be a part of gfx-hal. So we removed it, recommending `rendy-command` as a replacement. This slimmed up gfx-hal API surface and allowed us to straighten up the terminology (no more "RawXXX" or "XxxTyped"). | ||
|
|
There was a problem hiding this comment.
Previously, we recognized that the view of the API for the backends (when implementing it) needs to be different from the users (to use it).
We should try to clarify here that we tried to accommodate both in gfx, but eventually realized that the typed API is better left to other utility crates like rendy-command instead of trying to support both directly in gfx. In other words, the typed approach wasn't wrong, but we just didn't need it to be included directly within gfx.
We can also link to rendy-command here
|
|
||
| ## Feature-less wgpu-rs | ||
|
|
||
| From the very beginning of gfx-rs project, it was structured in a way that backend implementations of the API lived in separate crates. The user (or library client) was responsible to select the proper backend for their needs. It was very difficult for a client to support multiple backends within the same binary, and to our knowledge - nobody did. |
There was a problem hiding this comment.
It sounds a bit like we're saying it's difficult to do this correctly with gfx's design, but don't mention the trade-offs (i.e. benefits of being generic over the backend).
There was a problem hiding this comment.
It is extremely difficult to do this correctly.
|
|
||
| From the very beginning of gfx-rs project, it was structured in a way that backend implementations of the API lived in separate crates. The user (or library client) was responsible to select the proper backend for their needs. It was very difficult for a client to support multiple backends within the same binary, and to our knowledge - nobody did. | ||
|
|
||
| With the set of supported backends growing, this became more and more of an issue. Asking the user to enable the proper feature doesn't solve the problem - it just puts it on the users shoulders. Moreover, using features in such a way is typically non-idiomatic, because in Rust features are supposed to be additive, but most of the user code was written to work with a single backend, even if it's generic. |
There was a problem hiding this comment.
users shoulders -> users' shoulders
| From the very beginning of gfx-rs project, it was structured in a way that backend implementations of the API lived in separate crates. The user (or library client) was responsible to select the proper backend for their needs. It was very difficult for a client to support multiple backends within the same binary, and to our knowledge - nobody did. | ||
|
|
||
| With the set of supported backends growing, this became more and more of an issue. Asking the user to enable the proper feature doesn't solve the problem - it just puts it on the users shoulders. Moreover, using features in such a way is typically non-idiomatic, because in Rust features are supposed to be additive, but most of the user code was written to work with a single backend, even if it's generic. | ||
|
|
There was a problem hiding this comment.
Maybe we could try to clarify the role of backend and adapters in
The library knows which backends are supported on the target platform, it checks for their availability and enumerates their phusical adapters.
For example
The library knows which backends are supported on the target platform, so it's able to check the availability of each backend (i.e. whether Vulkan or DirectX12 is supported), then enumerate all physical adapters (i.e. graphics cards) for that backend.
|
|
||
| Today, we are happy to announce that the problem is solved in wgpu-rs! Features are gone. The library knows which backends are supported on the target platform, it checks for their availability and enumerates their phusical adapters. When the user requests an adapter, they can provide a mask of backends, and the implementation will pick the most suitable adapter on one of the enabled backends. | ||
|
|
||
| The immediate effect on the users is that the library "just works". All the complicated machinery of the backends is now hidden within the implementation. This is the case currently for `master` and will make it to the next release. |
There was a problem hiding this comment.
Could we clarify whether library is referring to wgpu-rs or the library using it (or both) here
|
|
||
| We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the gfx-hal build by a factor of 8.5X. | ||
|
|
||
| Secondly, the "typed" layer of gfx-hal got removed. Previously, we recognized that the view of the API for the backends (when implementing it) needs to be different from the users (to use it). Backends just need to implement "raw" interfaces, while users need more type safety, such as limiting the set of operations available on a command buffer when recording a render pass. This duality of APIs in gfx-hal worked to an extent. Providing safety was impossible without imposing some restrictions or overhead. At the end of the day, we decided that the "typed" (user-facing) layer is still useful, but it doesn't have to be a part of gfx-hal. So we removed it, recommending `rendy-command` as a replacement. This slimmed up gfx-hal API surface and allowed us to straighten up the terminology (no more "RawXXX" or "XxxTyped"). |
There was a problem hiding this comment.
Can we elaborate on the restrictions and/or overhead caused by providing the typed layer?
There was a problem hiding this comment.
From what I recall in gfx-hal-0.1 it was mostly type level stuff, so it mostly compiled out, but there were definite drawbacks in terms of it making the rustdoc much much harder to follow.
kvark
force-pushed
the
master
branch
2 times, most recently
from
b7cd6bc
to
ed38da9
Compare
kvark
force-pushed
the
master
branch
8 times, most recently
from
9f01f48
to
e02e7e1
Compare
A draft for the feature-less update