search

TheFuseLab / VL.Fuse

A library for visually programming on the GPU, built to enable rapid workflows and modular approaches to accelerated graphics, logic and computation.
https://www.thefuselab.io
MIT License
262 stars 20 forks source link

Allow multiple individual sinks for GpuValue #42

Open tebjan opened 2 years ago

tebjan commented 2 years ago

basically, every input value has to track compilations and generate a new input for every sink.

see this PR: https://github.com/vvvv/VL.Stride/pull/451

everyoneishappy commented 2 years ago

Demo for this in VL.Fuse\R&D_Issues\GpuInTwiceBug.vl

texone commented 2 years ago

Double checked everything looks like at least the patch provided by kyle is working now although I have not specifically fixed anything might be a side effect of something else not sure, Do you have anything else to test this Kyle? Otherwise would close it.

everyoneishappy commented 2 years ago

For me the demo patch still shows the broken behavior. Are you sure don't have part of the graph cached or something? image

everyoneishappy commented 1 year ago

@tebjan Are you able to give any feedback on the updated demo patch? \R&D_Issues\42#GpuInTwiceBug.vl @texone mentioned he is stuck with this although had tried to copy your approach

It's quite a big limitation as it stands

tebjan commented 1 year ago

Late reply because the GitHub notifications didn't reach me in the past weeks.

This topic sounds like something that @azeno is comfortable with. I've lost track of the code a little bit after the mentioned pull request. It's quite complex at the moment and for me hard to decipher. I think in VL.Stride it needs a cleanup and good code documentation so that fuse can follow the guidelines.

The main idea however is, that the shader compilation context is the identifier for one particular shader that gets built. It can be used as key for IDs, input pins and other things that have to be unique per shader. It can also help with gathering information that has to be shared between different nodes that aren't aware of each other, such as multiple from/to ShaderFX nodes that have to cooperate when a shader gets built.

texone commented 1 year ago

Yes I was also rethinking this for materials as this seems to be the main usecase I would propse for materials we use semantics and materialextension and than override the shading stage to set the semantics currently every value would be recalculated even if it shares a lot of calculations with another node image Is it potentially possible to connect two material extensions? I would move the setup of the semantics into the fuse pbrmaterial so that the user does not need to take care of it

azeno commented 1 year ago

Hmm not sure we're on the same page here. I thought this is about the constant buffers getting generated per sink and each source needs to keep track of?