-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📀 Make wgpu
an optional dependency
#359
Conversation
d24aea1
to
bb456c3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't like quite how many cfg(feature="wgpu")
there are here. I can already foresee a significant number of changes running into "oh, this needs wpgu".
I think the recommended approach for other renderers might be to use the shaders crate? (That might only be for non-Rust languages though, I've not looked into it too much)
@@ -23,6 +23,8 @@ jobs: | |||
- run: cargo check --workspace | |||
# Check vello (the default crate) without the features used by `with_winit` for debugging | |||
- run: cargo check | |||
# Check vello (the default crate) without wgpu | |||
- run: cargo check --no-default-features |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long does this check take?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CI run for that step (on this PR) was ~3 seconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough! Useful to have it documented here though. I've got no objection to adding this check on that metric then.
pub struct Id(NonZeroU64); | ||
pub struct Id(pub NonZeroU64); | ||
|
||
static ID_COUNTER: AtomicU64 = AtomicU64::new(0); | ||
|
||
#[cfg(feature = "wgpu")] | ||
pub struct Engine { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These sections together are a bit strange
This suggests the engine module is too entangled with wgpu/that these IDs shouldn't be in this module.
If this is the wgpu engine implementation, it should maybe be more separated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like at least there was an intention behind splitting Engine
and Recording
up, maybe moving all of the Engine
stuff to a wgpu.rs
file is better going forward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, anybody implementing another Engine
type thing would need access to these internals to be able to translate between Recording
and it's own internal representation since the Engine
is responsible for handing these out.
src/util.rs
Outdated
@@ -175,6 +175,7 @@ impl std::task::Wake for NullWake { | |||
/// Block on a future, polling the device as needed. | |||
/// | |||
/// This will deadlock if the future is awaiting anything other than GPU progress. | |||
#[cfg(feature = "wgpu")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this double cfg(wgpu)
ed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad - I later realized this entire file was just wgpu helpers.
bb456c3
to
9bb675a
Compare
Very interesting to see this! The The direction I'd like to see is that |
9bb675a
to
a264033
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's land this, as it's a fairly minimal change so won't have much conflict with other work in flight. As a followup, I think we should move the wgpu backend into a separate rs file, to make the granularity of the cfg coarser. I've done enough experimentation to be confident that will be straightforward.
Thanks!
linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `velato` will be forced to opt in to `wgpu` due to not disabling the default here.
linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `velato` will be forced to opt in to `wgpu` due to not disabling the default here.
linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `velato` will be forced to opt in to `wgpu` due to not disabling the default here.
…feature linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `velato` will be forced to opt in to `wgpu` due to not disabling the default here. Since `velato` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `vello-wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies.
linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `vello_svg` will be forced to opt in to `wgpu` due to not disabling the default here. Since `vello_svg` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `vello-wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies.
…feature linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `vello_svg` will be forced to opt in to `wgpu` due to not disabling the default here. Since `vello_svg` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `vello-wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies.
…ature linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `velato` will be forced to opt in to `wgpu` due to not disabling the default here. Since `velato` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies.
…ature linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `vello_svg` will be forced to opt in to `wgpu` due to not disabling the default here. Since `vello_svg` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies.
…feature (#10) linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `vello_svg` will be forced to opt in to `wgpu` due to not disabling the default here. Since `vello_svg` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `vello-wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies. Same change as linebender/velato#17.
#10) linebender/vello#359 made `wgpu` an optional but default dependency/feature, but any crate using `vello_svg` will be forced to opt in to `wgpu` due to not disabling the default here. Since `vello_svg` does not need any rendering backend at all, this feature should be disabled by default. As the `vello` crate is reexported from the root, a `vello-wgpu` passthrough feature is provided so that users can turn it back on without explicitly depending on `vello` in their crate dependencies. Same change as linebender/velato#17.
This turns
wgpu
into an optional dependency that's default enabled.In our project we're not using
wgpu
as the renderer so interop-ing with this library is a bit trick, but I think I've find a way that would work for us. We can take the pre-recorded command bufferRecording
and convert it to our own abstraction.As for the shaders, we can use naga and patch files to make them work in our environment.
@raphlinus We disccussed various ways of going about this problem some time ago, but I think this wouldn't be too intrusive on either of our projects. If it is, let me know.