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

API and design improvements for gxeng node system #51

Open
petiaccja opened this issue Dec 24, 2019 · 0 comments
Open

API and design improvements for gxeng node system #51

petiaccja opened this issue Dec 24, 2019 · 0 comments

Comments

@petiaccja
Copy link
Owner

petiaccja commented Dec 24, 2019

So... the node system wanted to be everything but got a little twisted.

Issues while creating a render node:

  1. getting inputs/outputs is ugly: GetInput<0>().Get() uhh
  2. passing data from Setup to Execute via member variables
  3. buffers cached internally until input size changes (checks are ugly)
  4. Reset is cumbersome, often forgotten -> unwanted swapchain refs
  5. member variables are:
    • PSOs
    • Binders
    • RTVs/DSVs/SRVs
    • non-transient resources: vbs, ibs, textures

Solutions:

  1. Either rename methods or change system.
    • Use GetInputPort<0>() and GetInputParam<0>().
    • InputPortConfig<Args...> should have Update(Args...), and make framework do the ugly work
  2. Setup return std::any -> which is passed to Execute, contains all per-frame state
    • creating buffers is cheap (cached or placed resources)
    • creating views is (is it?) cheap: only a few in numbers
  3. Caching not needed with 2., or simply done externally in scheduler
    • views and textures no longer need to reset (passed via 2.)
    • PSOs, Binders are reset situationally, no refernce to swapchain
    • inputs which are connected can be automatically cleared
  4. member variables would be:
    • PSOs
    • Binders
    • non-transient resources: vbs, ibs, textures
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant