Skip to content
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

Merged
merged 1 commit into from
Sep 15, 2023

Conversation

Jasper-Bekkers
Copy link
Collaborator

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 buffer Recording 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.

Copy link
Member

@DJMcNab DJMcNab left a 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
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Member

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.

Comment on lines -35 to 41
pub struct Id(NonZeroU64);
pub struct Id(pub NonZeroU64);

static ID_COUNTER: AtomicU64 = AtomicU64::new(0);

#[cfg(feature = "wgpu")]
pub struct Engine {
Copy link
Member

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?

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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")]
Copy link
Member

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?

Copy link
Collaborator Author

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.

@raphlinus
Copy link
Contributor

Very interesting to see this!

The Engine abstraction was designed to support multiple GPU execution engines, and we are doing some work with just using the shaders, and a separate crate for encoding (completely reimplementing the dispatching.

The direction I'd like to see is that Engine is factored so that Recording is in its own module that would always be present, but all of Engine and its dependencies would be gated by a single feature gate. An even sharper separation would be to have that as a separate crate, but that might increase friction for making further changes to the engine (see #360, as well as changes needed to support WGPU extensions, including f16, subgroups, and descriptor indexing). But I can see this as a reasonable first step; slightly messy but not a massive impact on the code.

Copy link
Contributor

@raphlinus raphlinus left a 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!

@Jasper-Bekkers Jasper-Bekkers merged commit 34d313d into linebender:main Sep 15, 2023
4 checks passed
MarijnS95 added a commit to MarijnS95/velato that referenced this pull request Apr 29, 2024
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.
MarijnS95 added a commit to MarijnS95/vello_svg that referenced this pull request Apr 29, 2024
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.
MarijnS95 added a commit to MarijnS95/velato that referenced this pull request Apr 29, 2024
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.
MarijnS95 added a commit to MarijnS95/velato that referenced this pull request May 3, 2024
…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.
MarijnS95 added a commit to MarijnS95/vello_svg that referenced this pull request May 3, 2024
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.
MarijnS95 added a commit to MarijnS95/vello_svg that referenced this pull request May 3, 2024
…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.
MarijnS95 added a commit to MarijnS95/velato that referenced this pull request May 4, 2024
…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.
MarijnS95 added a commit to MarijnS95/vello_svg that referenced this pull request May 4, 2024
…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.
github-merge-queue bot pushed a commit to linebender/vello_svg that referenced this pull request May 5, 2024
…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.
github-merge-queue bot pushed a commit to linebender/vello_svg that referenced this pull request May 5, 2024
#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants