Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft PR? yeah, this is not directly for merge. Instead, this is a research of how a Render Graph for vello could look like. My thoughts are below, please share yours.
Other than most of the other graphical application who drive a render graph, vello needs to know the size (for a buffer) or width,heigth (for an image) for a resource, while it creates them dynamically in the render nodes/stages. So a simple "just create a static buffer of that size and give it to this node" doesn't quite work. What I have done is somewhat quite overengineered/overkill I think, so I would love to hear simpler ideas from you. Basically, every node has an output struct and when linking the nodes, you can already specify how the outcome of a dependency will be used for the node. Then with some type erasure magic I store all the outputs of the nodes and when all dependencies are resolved, we cast them back for the node to get its inputs.
I haven't removed the old code in
render.rs
, but it isn't used anymore. Also, I just now see how many resources we create, I wonder how long we are able to run before we run out of the u64 (probably loooong, but still feels itchy).Also, I implemented some cool helpers for recording such as that now, dispatch doesn't get an array, but rather a tuple where we can now pass different
impl Into<ResourceProxy>
structs likeImageProxy
,BufferProxy
,ResourceProxy
at once without having to call.into()
on the different ones.All special stuff like reusing resources isn't implemented yet (where I also wonder how we would do that exactly... because even with "the same buffer" (being the same usage) could just be bigger on the next iteration.. hmm)
So yeah just a basic prototype, which at least runs, to get one example of how it could look and gather feedback. :>