Implement generic pipeline caching in WgpuExecutor#4210
Implement generic pipeline caching in WgpuExecutor#4210timon-schelling wants to merge 10 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request refactors the WGPU pipeline execution model by introducing a dynamic, generic Pipeline trait system. Hardcoded compositor and resampler fields in WgpuExecutor are replaced with a thread-safe pipelines map that caches and runs pipelines dynamically. Additionally, the render_background and pixel_preview (renamed to render_pixel_preview) nodes have been refactored to use this new system. Feedback on these changes suggests adding an early return in render_background when viewport_zoom <= 0.0 to prevent uninitialized texture returns, simplifying the Pipeline trait using impl Future to avoid boxed future allocations, releasing the RwLockReadGuard earlier during pipeline retrieval, and cleaning up a verbose type signature in BackgroundCompositor::run.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| pub trait Pipeline: std::any::Any + Send + Sync + Sized { | ||
| type Args<'a>; | ||
| type Out: Send; | ||
|
|
||
| fn create(context: &WgpuContext) -> Self; | ||
|
|
||
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out>; | ||
| } | ||
|
|
||
| pub trait AsyncPipeline: std::any::Any + Send + Sync + Sized { | ||
| type Args<'a>; | ||
| type Out: Send; | ||
|
|
||
| fn create(context: &WgpuContext) -> Self; | ||
|
|
||
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> impl Future<Output = Self::Out> + Send + 'a; | ||
| } | ||
|
|
||
| impl<P: AsyncPipeline> Pipeline for P { | ||
| type Args<'a> = <P as AsyncPipeline>::Args<'a>; | ||
| type Out = <P as AsyncPipeline>::Out; | ||
|
|
||
| fn create(context: &WgpuContext) -> Self { | ||
| <P as AsyncPipeline>::create(context) | ||
| } | ||
|
|
||
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out> { | ||
| Box::pin(<P as AsyncPipeline>::run(self, executor, args)) | ||
| } | ||
| } |
There was a problem hiding this comment.
Since WgpuExecutor::run_pipeline always downcasts to the concrete pipeline type P, there is no need for a trait object or boxed futures. We can leverage Rust's support for impl Future in traits to define a single Pipeline trait without any boxing, eliminating the Box::pin allocation on every pipeline execution.
| pub trait Pipeline: std::any::Any + Send + Sync + Sized { | |
| type Args<'a>; | |
| type Out: Send; | |
| fn create(context: &WgpuContext) -> Self; | |
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out>; | |
| } | |
| pub trait AsyncPipeline: std::any::Any + Send + Sync + Sized { | |
| type Args<'a>; | |
| type Out: Send; | |
| fn create(context: &WgpuContext) -> Self; | |
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> impl Future<Output = Self::Out> + Send + 'a; | |
| } | |
| impl<P: AsyncPipeline> Pipeline for P { | |
| type Args<'a> = <P as AsyncPipeline>::Args<'a>; | |
| type Out = <P as AsyncPipeline>::Out; | |
| fn create(context: &WgpuContext) -> Self { | |
| <P as AsyncPipeline>::create(context) | |
| } | |
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out> { | |
| Box::pin(<P as AsyncPipeline>::run(self, executor, args)) | |
| } | |
| } | |
| pub trait Pipeline: std::any::Any + Send + Sync + Sized { | |
| type Args<'a>; | |
| type Out: Send; | |
| fn create(context: &WgpuContext) -> Self; | |
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> impl Future<Output = Self::Out> + Send + 'a; | |
| } |
There was a problem hiding this comment.
No
error: lifetime bound not satisfied
--> node-graph/nodes/gstd/src/render_background.rs:17:1
|
17 | #[node_macro::node(category(""))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is a known limitation that will be removed in the future (see issue #100013 <https://github.com/rust-lang/rust/issues/100013> for more information)
= note: this error originates in the attribute macro `node_macro::node` (in Nightly builds, run with -Z macro-backtrace for more info)
error: lifetime bound not satisfied
--> node-graph/nodes/gstd/src/render_pixel_preview.rs:13:1
|
13 | #[node_macro::node(category(""))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is a known limitation that will be removed in the future (see issue #100013 <https://github.com/rust-lang/rust/issues/100013> for more information)
= note: this error originates in the attribute macro `node_macro::node` (in Nightly builds, run with -Z macro-backtrace for more info)
There was a problem hiding this comment.
7 issues found across 15 files
Confidence score: 2/5
- There is a concrete user-facing regression risk in
node-graph/nodes/gstd/src/render_background.rs: thezoom <= 0early return can skip compositing/copying and produce a blank render output. - Several high-confidence panic paths were introduced (
unwrap/expectand unwrappedapplication_io) acrossnode-graph/nodes/gstd/src/render_background.rsandnode-graph/libraries/wgpu-executor/src/lib.rs, which can crash runtime/executor flows instead of failing gracefully. - Additional executor-path concerns in
node-graph/libraries/wgpu-executor/src/pipeline.rsandnode-graph/libraries/wgpu-executor/src/lib.rs(per-call boxing in a hot path, eager duplicate pipeline creation, and longer-than-needed lock scope) increase performance/concurrency risk but are secondary to correctness issues. - Pay close attention to
node-graph/nodes/gstd/src/render_background.rs,node-graph/libraries/wgpu-executor/src/lib.rs,node-graph/libraries/wgpu-executor/src/pipeline.rs- potential blank output, panic-on-error behavior, and executor hot-path regressions.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="node-graph/libraries/wgpu-executor/src/pipeline.rs">
<violation number="1" location="node-graph/libraries/wgpu-executor/src/pipeline.rs:35">
P2: Pipeline dispatch now boxes every async run, adding per-call heap allocation in a hot executor path.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| } | ||
|
|
||
| fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out> { | ||
| Box::pin(<P as AsyncPipeline>::run(self, executor, args)) |
There was a problem hiding this comment.
P2: Pipeline dispatch now boxes every async run, adding per-call heap allocation in a hot executor path.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At node-graph/libraries/wgpu-executor/src/pipeline.rs, line 35:
<comment>Pipeline dispatch now boxes every async run, adding per-call heap allocation in a hot executor path.</comment>
<file context>
@@ -0,0 +1,37 @@
+ }
+
+ fn run<'a>(&'a self, executor: &'a WgpuExecutor, args: &'a Self::Args<'_>) -> PipelineFuture<'a, Self::Out> {
+ Box::pin(<P as AsyncPipeline>::run(self, executor, args))
+ }
+}
</file context>
There was a problem hiding this comment.
likely blocked by
error: lifetime bound not satisfied
--> node-graph/nodes/gstd/src/render_background.rs:17:1
|
17 | #[node_macro::node(category(""))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is a known limitation that will be removed in the future (see issue #100013 <https://github.com/rust-lang/rust/issues/100013> for more information)
= note: this error originates in the attribute macro `node_macro::node` (in Nightly builds, run with -Z macro-backtrace for more info)
error: lifetime bound not satisfied
--> node-graph/nodes/gstd/src/render_pixel_preview.rs:13:1
|
13 | #[node_macro::node(category(""))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is a known limitation that will be removed in the future (see issue #100013 <https://github.com/rust-lang/rust/issues/100013> for more information)
= note: this error originates in the attribute macro `node_macro::node` (in Nightly builds, run with -Z macro-backtrace for more info)
There was a problem hiding this comment.
Thanks for the heads-up — that looks like a blocking compiler limitation.
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="node-graph/libraries/wgpu-executor/src/lib.rs">
<violation number="1" location="node-graph/libraries/wgpu-executor/src/lib.rs:103">
P2: `P::create()` now executes while the `pipelines` write lock is held, introducing avoidable lock contention during expensive pipeline construction.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| .write() | ||
| .unwrap() | ||
| .entry(key) | ||
| .or_insert_with(|| Arc::new(P::create(&self.context))) |
There was a problem hiding this comment.
P2: P::create() now executes while the pipelines write lock is held, introducing avoidable lock contention during expensive pipeline construction.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At node-graph/libraries/wgpu-executor/src/lib.rs, line 103:
<comment>`P::create()` now executes while the `pipelines` write lock is held, introducing avoidable lock contention during expensive pipeline construction.</comment>
<file context>
@@ -91,17 +91,16 @@ impl WgpuExecutor {
.unwrap()
.entry(key)
- .or_insert(built)
+ .or_insert_with(|| Arc::new(P::create(&self.context)))
.clone()
.downcast::<P>()
</file context>
changing shader nodes to work with this will be done in a followup PR, for now they keep the separate
ShaderRuntime.