Merge pull request #64 from chromy/patch-1

Add a missing word

_posts/2021-11-04-prefix-sum-portable.md

@@ -66,7 +66,7 @@ I'm also starting to populate the tests/ subdirectory of the [piet-gpu repo] wit
 
 ## Progress on progress
 
-One controversial aspect of the original decoupled look-back algorithm is that it depends a forward progress guarantee from the GPU. If a workgroup is running, and an adversarial scheduler unfairly schedules threads that are waiting on the flag in favor of threads that would set it if they were run, then the dispatch as a whole will hang (this is similar to a deadlock in a classical setting, but a bit more subtle). My code from last year also depended on this guarantee, and while it ran well on the hardware I tested on, it might not everywhere. The Vulkan specification itself is careful to make no forward progress guarantees.
+One controversial aspect of the original decoupled look-back algorithm is that it depends on a forward progress guarantee from the GPU. If a workgroup is running, and an adversarial scheduler unfairly schedules threads that are waiting on the flag in favor of threads that would set it if they were run, then the dispatch as a whole will hang (this is similar to a deadlock in a classical setting, but a bit more subtle). My code from last year also depended on this guarantee, and while it ran well on the hardware I tested on, it might not everywhere. The Vulkan specification itself is careful to make no forward progress guarantees.
 
 There are a number of interesting workloads that depend on or benefit from these kind of properties, likely including the Nanite renderer. To help those applications, Tyler Sorensen's group has been characterizing existing GPUs, with the aim of defining a GPU property that might be queried at runtime. Their latest paper is [Specifying and Testing GPU Workgroup Progress Models]. Among its findings, Apple and ARM exhibit failures of forward progress, so it cannot be specified in the Vulkan core, but only as an optional property.