
High-Level Rendering Using Render Graphs - adamnemecek
http://ourmachinery.com/post/high-level-rendering-using-render-graphs/
======
annywhey
The trend is clear: Rendering engines are becoming compilers.

At the dawn of real-time rendering everything was both bespoke and fixed-
function. You would call a different optimized codepath to draw a floor, a
wall, or a ceiling. If the platform was amenable to it you might use self-
modifying code to optimize the time/space tradeoff. The datasets were small
enough that a simple array was always the default "right" choice until you
were running out of memory.

Gradually the demands generalized and became more algorithmic than low-level
in nature. DOOM's best-known optimization was in using BSP for visibility.

Now - while there's still a great demand for smarter algorithms - most of the
pipeline complexity comes in this kind of generalized dependency analysis
stuff to maximize use of resources across a broad, complex, configurable
pipeline without hand-tuning everything, which is a familiar compiler problem
to have.

~~~
Mr_P
One of the best talks at Siggraph last year was on Bungie's particle system
Destiny 2 (slides are here:
[http://advances.realtimerendering.com/s2017/index.html](http://advances.realtimerendering.com/s2017/index.html)).
The talk was an elegant breakdown of how they (1) created a CPU interpreter
for a domain specific language describing particle parameters, (2) ported it
to the GPU (even running an interpreter on the GPU for parts of the production
game!), and (3) how they converted it into a compiler for the obvious
performance wins.

Apparently running bytecode interpreters on the GPU is not uncommon:
[https://dolphin-emu.org/blog/2017/07/30/ubershaders/](https://dolphin-
emu.org/blog/2017/07/30/ubershaders/)

------
tbabb
Long post about rendering.

Not a single pretty image.

What gives?

~~~
phkahler
Yeah, I started skimming and at the end got the impression it was a thought
piece and the author hadn't even coded anything yet. I also kept wondering why
the new terminology instead of "scene graph". There's probably a difference,
but I didn't find it compelling enough to read in depth.

~~~
jbister
A scene graph and a "render graph"/Frame graph in Frostbite terminology are
not the same. I would recommend checking out:

[http://www.gdcvault.com/play/1024656/Advanced-Graphics-
Tech-...](http://www.gdcvault.com/play/1024656/Advanced-Graphics-Tech-Moving-
to) and [https://www.gdcvault.com/play/1024612/FrameGraph-
Extensible-...](https://www.gdcvault.com/play/1024612/FrameGraph-Extensible-
Rendering-Architecture-in)

for a more in depth view.

I would describe it as such: A scene graph specifies _what_ needs to be drawn,
while a render graph specifies _how_ it should be drawn and what the
dependencies of each step in drawing is. For example, a render graph is used
to reduce the number of image layout transitions in a frame by looking at what
layout is expected for each operation and figuring out where to put the layout
transitions, instead of letting a human place the layout transitions which
will inevitably lead to unnecessary transitions when the scene becomes complex
enough.

I didn't think this article was bad even if it is maybe less concrete than the
slides I linked.

------
DerSaidin
Imo a group of Passes should be called a Stage or a Phase, not a module. The
terms module is too easy to overload.

