5 ms·

The concept in this blogpost anticipates a more general architecture. Graphics pipelines are a good fit for dataflow programming, such as FBP [0] or reactive [1

The concept in this blogpost anticipates a more general architecture. Graphics pipelines are a good fit for dataflow programming, such as FBP [0] or reactive [1]. When you use those styles, the pipeline architecture is more flexible, more straightforward to run concurrently, while the coding challenge turns into one of how to allocate and address different assets, address different types of assets, create and address temporary data, and describe the node graph connecting these things together. The practical complication in rendering can be stated like this: combine assets A and B and parameter P to make asset C, then (subsequently) combine asset C with asset D and parameter J to make output O. Some of the assets/parameters change with each frame rendered, others are entirely static, and oversight over GPU time and memory usage is needed, so you have to consider which things are loaded when. Then, while in production, a design change necessitates that a new parameter be added somewhere, and it turns out that you have to reorder which things are processed first and add a custom codepath because one of your target GPUs doesn't support the feature you need without a hack. [0] https://en.wikipedia.org/wiki/Flow-based_programming https://en.wikipedia.org/wiki/Flow-based_programming [1] https://en.wikipedia.org/wiki/Reactive_programming https://en.wikipedia.org/wiki/Reactive_programming

amelius 10y ago
Why not simply use a software cache (memoization, [1]) to prevent doing things more often than necessary? [1] https://en.wikipedia.org/wiki/Memoization https://en.wikipedia.org/wiki/Memoization
- MaulingMonkey 10y ago
  All kinds of caches are used in graphics programming. The devil is in the details: Does a generic memoization strategy help you decide when to re-render a shadowmap based on the updating of entities within range of said shadowmap? And when you decide technically incorrect, stale results, are still 'good enough' (based on the duration they've been stale, distance from the camera, size of the resulting shadows, etc.) how do you represent that? How do you decide when shadowmaps can been reused between multiple perspectives? How much can you calculate offline, before the game is even run? If you squint really hard you might be able to couch some of this in memoization terms - but how, exactly, is that helping? Memory is tight - GPU memory might be a few gigs, and your artists will fill the space. Time is tight - 16ms/frame max if you're targeting a smooth 60fps, and even higher framerates (and tighter time budgets) are recommended to e.g. reduce nausea for VR. You know exactly how long you need some resources, they are large (over 100MB for a single set of 4k gbuffers), and spilling active data out of the cache can be disastrously slow, or lose necessary information you cannot recreate. At some point you'll get rather hands on and start micromanaging a lot of this stuff - it's much simpler to write, debug, and optimize a lot of this if you implement it 'by hand', than to design, write, debug, and optimize an algorithm trying to handle a perfectly generic answer/solution to all these problems.

amelius 10y ago

Why not simply use a software cache (memoization, [1]) to prevent doing things more often than necessary? [1] https://en.wikipedia.org/wiki/Memoization https://en.wikipedia.org/wiki/Memoization

MaulingMonkey 10y ago
All kinds of caches are used in graphics programming. The devil is in the details: Does a generic memoization strategy help you decide when to re-render a shadowmap based on the updating of entities within range of said shadowmap? And when you decide technically incorrect, stale results, are still 'good enough' (based on the duration they've been stale, distance from the camera, size of the resulting shadows, etc.) how do you represent that? How do you decide when shadowmaps can been reused between multiple perspectives? How much can you calculate offline, before the game is even run? If you squint really hard you might be able to couch some of this in memoization terms - but how, exactly, is that helping? Memory is tight - GPU memory might be a few gigs, and your artists will fill the space. Time is tight - 16ms/frame max if you're targeting a smooth 60fps, and even higher framerates (and tighter time budgets) are recommended to e.g. reduce nausea for VR. You know exactly how long you need some resources, they are large (over 100MB for a single set of 4k gbuffers), and spilling active data out of the cache can be disastrously slow, or lose necessary information you cannot recreate. At some point you'll get rather hands on and start micromanaging a lot of this stuff - it's much simpler to write, debug, and optimize a lot of this if you implement it 'by hand', than to design, write, debug, and optimize an algorithm trying to handle a perfectly generic answer/solution to all these problems.