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

[Experimental] Render Graph v1 #574

Draft
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

DasLixou
Copy link
Collaborator

@DasLixou DasLixou commented May 11, 2024

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 like ImageProxy, 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. :>

@DJMcNab DJMcNab mentioned this pull request Jun 10, 2024
3 tasks
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.

1 participant