This is a response to the criticism in a recent post called Projective Geometric Algebra Done Right of work done in the 2019 SIGGRAPH presentation “Geometric Algebra for Graphics Engineers” (I did not personally create the SIGGRAPH presentation, but I do subscribe to its conclusions). I mean no ill-will to the author (I even have a couple of his books!), but felt somewhat compelled to write this response because I believe the view espoused actually prevents a more intuitive grasp of the concepts therein. Central to the debate is how geometers should represent projective space algebraically. Namely, what possible representations are there and what are the tradeoffs? I can’t get into the entirety of Geometric Algebra in just a blogpost (that will need to be a longer form writeup), so be advised that this is written for people that have had some brushes with GA already. All quoted text in this article is lifted verbatim from the source material as of this writing. So without further ado, let’s dig into it.

When I implemented my own render graph, I needed to make a number of decisions for proceeding and wanted to record the various considerations for authoring such a library. By way of background, a render graph is an acyclic directed graph of nodes, each of which may consume a set of resources and produce a set of resources. Edges in the graph denote an execution dependency (the child node should happen after the parent), with the caveat that the dependency need not be a full pipeline barrier. For example, a parent node may produce results A and B, but a child node may only depend on A. Another caveat is that the dependencies may be relaxed to allow some overlapping. For example, a parent node may produce some result in its fragment stage which is consumed in the fragment stage of a child node. In such a case, the child node can execute its vertex stage while the parent node is also executing its vertex stage.

This is part II (and possibly the final part) on this series titled the Vulkan Synchronization Primer. For the first part, click here.

The intent of this post is to provide a mental model for understanding the various synchronization nouns, verbs, and adjectives Vulkan offers. In particular, after reading this series, hopefully, you’ll have a good understanding of what problems exist, when you should use which sychronization feature, and what is likely to perform better or worse. There are no real prerequisites to reading this, except that you’ve at least encountered a few barriers in tutorial or sample code. I would guess that many readers might have also tried to read the standard on synchronization (with varying degrees of success).