More proofreading

handouts/src/29-finish-him.md

@@ -42,27 +42,27 @@ are some possible tracks that you may want to explore:
   extension may or may not be present), which will likely require some code
   duplication.
 - Our microbenchmarks tell us that our GPU is not quite operating at peak
-  throughput when processing a single 1920x1080 images. It would be nice to try
+  throughput when processing a single 1920x1080 image. It would be nice to try
   processing multiple images in a single compute dispatch, but this will require
   implementing a global synchronization protocol during the execution of a
   single kernel, which will require very fancy/tricky lock-free programming in
   global memory.
 - So far, we have not attempted to overlap GPU computing with CPU-GPU data
   transfers, as those data transfers were relatively inexpensive with respect to
-  both compute and storage I/O costs. But if we optimize compute, this may
-  change. We would then want to allocate a dedicated data transfer queue, and
-  carefully tune our resource allocations so that those that need to be
+  both compute and storage I/O costs. But if we optimize compute enough, this
+  may change. We would then want to allocate a dedicated data transfer queue,
+  and carefully tune our resource allocations so that those that need to be
   accessible from both queues are actually marked as such. And then we will need
   to set up a third image as a GPU-side staging buffer (so the double buffer can
   still be used for compute when a data transfer is ongoing) and refine our 
   CPU/GPU synchronization logic to get the compute/transfer overlap to work.
 
-And then, of course, there are the other GPU APIs that are available from Rust.
-How much performance do we lose when we improve portability by using `wgpu`
-instead of Vulkan? How far along is `rust-gpu` these days, and is `krnl` any
-close to the portable CUDA clone that it aims to be? These are all interesting
-questions, that we should probably explore once we have a good Vulkan version as
-a reference point that tells us what a mature GPU API is capable of.
+Also, there are the other GPU APIs that are available from Rust. How much
+performance do we lose when we improve portability by using `wgpu` instead of
+Vulkan? How far along is `rust-gpu` these days, and is `krnl` any close to the
+portable CUDA clone that it aims to be? These are all interesting questions,
+that we should probably explore once we have a good Vulkan version as a
+reference point that tells us what a mature GPU API is capable of.
 
 As you can probably guess at this point, GPU computing is not immune to old
 software project management wisdom: once you are done with the first 90% of a