diff --git a/README.md b/README.md
index 89f69c5f3..2bba6201b 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,6 @@ glslangValidator and spirv-tools to additionally target SPIR-V.
 * [Introduction: my shader is being weird, now what?](docs/glsl-reduce-intro.md)
 * [glsl-reduce walkthrough](docs/glsl-reduce-walkthrough.md)
 * [glsl-reduce manual](docs/glsl-reduce.md)
-* [Developer documentation](docs/glsl-fuzz-develop.md)
 
 ### glsl-fuzz
 
@@ -27,13 +26,12 @@ glslangValidator and spirv-tools to additionally target SPIR-V.
 * [glsl-fuzz walkthrough](docs/glsl-fuzz-walkthrough.md)
 * [glsl-generate manual](docs/glsl-fuzz-generate.md)
 * [glsl-reduce manual (for reducing fuzzed shaders)](docs/glsl-fuzz-reduce.md)
-* [Developer documentation](docs/glsl-fuzz-develop.md)
 
 ## Get the GraphicsFuzz tools
 
 
 * **Pre-built binaries** are available on the [GitHub releases page](docs/glsl-fuzz-releases.md)
-* [**Build instructions**](docs/glsl-fuzz-develop.md)
+* [**Developer documentation with build instructions**](docs/glsl-fuzz-develop.md)
 
 
 ## Contribute
diff --git a/build/travis/release.py b/build/travis/release.py
index 008536f28..51d5fcc7d 100644
--- a/build/travis/release.py
+++ b/build/travis/release.py
@@ -29,6 +29,10 @@ def go():
         print("Skipping release because this is not the master branch.")
         sys.exit(0)
 
+    if "TRAVIS_TAG" not in os.environ:
+        print("Skipping release because this is not a tag build")
+        sys.exit(0)
+
     if "TRAVIS_PULL_REQUEST" in os.environ and os.environ["TRAVIS_PULL_REQUEST"] != "false":
         print("Skipping release because this is a pull request.")
         sys.exit(0)
@@ -37,6 +41,7 @@ def go():
         print("Please define TRAVIS_COMMIT")
         sys.exit(1)
     commit_hash = os.environ["TRAVIS_COMMIT"]
+    tag_name = os.environ["TRAVIS_TAG"]
 
     if not os.path.isdir("out"):
         print("Failing release because 'out' directory was not found.")
@@ -51,7 +56,7 @@ def go():
     subprocess.check_call([
         "github-release",
         repo_name,
-        "v-" + commit_hash,
+        tag_name,
         commit_hash,
         description + "\n" + git_log,
         "out/*"])
diff --git a/docs/glsl-fuzz-develop.md b/docs/glsl-fuzz-develop.md
index 029de194e..ff13d3e3f 100644
--- a/docs/glsl-fuzz-develop.md
+++ b/docs/glsl-fuzz-develop.md
@@ -14,8 +14,13 @@ page](glsl-fuzz-releases.md).
 * [JDK 1.8+](http://www.oracle.com/technetwork/java/javase/downloads/index.html)
 * [Maven](https://maven.apache.org/)
 * [Python](https://www.python.org/)
-* For Android workers: [Android SDK & NDK](https://developer.android.com/studio/#command-tools)
-* For Vulkan worker: [Vulkan SDK](https://vulkan.lunarg.com/sdk/home)
+
+* For our Android workers: [Android SDK & NDK](https://developer.android.com/studio/#command-tools)
+* For the Vulkan desktop worker: [Vulkan SDK](https://vulkan.lunarg.com/sdk/home)
+
+> Our *workers* are applications that run on the device you wish to test;
+> they communicate with the `glsl-server` application that is typically run on
+> a more powerful x86 machine.
 
 ### Get a local copy of this repository
 
@@ -24,17 +29,14 @@ To clone this repository:
 ```sh
 git clone https://github.com/google/graphicsfuzz.git
 
-# Or: git clone git@github.com:google/graphicsfuzz.git
-
 # Change into the cloned directory:
 cd graphicsfuzz
 ```
 
-The Vulkan worker build also requires git submodules to be cloned:
+The Vulkan worker build requires git submodules to be initialized and updated:
 
 ```sh
-git submodule init
-git submodule update
+git submodule update --init
 ```
 
 ### Build the GraphicsFuzz package
@@ -204,11 +206,10 @@ git clone https://github.com/google/graphicsfuzz.git
 cd graphicsfuzz
 ```
 
-The Vulkan worker build also requires git submodules to be cloned:
+The Vulkan worker build requires git submodules to be initialized and updated:
 
 ```sh
-git submodule init
-git submodule update
+git submodule update --init
 ```
 
 ### Opening GraphicsFuzz in IntelliJ
@@ -342,7 +343,7 @@ manager.queueCommand(
     "shaderfamilies/shaderfamily1/variants/variant_1.json",
     "IDENTICAL",
     "--server", "http://localhost:8080",
-    "--woker", "my-laptop"
+    "--worker", "my-laptop"
    ],
    "my-laptop",
    "processing/my-laptop/shaderfamily1/reductions/variant_1/command.log")
diff --git a/docs/glsl-fuzz-generate.md b/docs/glsl-fuzz-generate.md
index 135273f7a..577d28746 100644
--- a/docs/glsl-fuzz-generate.md
+++ b/docs/glsl-fuzz-generate.md
@@ -4,8 +4,31 @@
 
 `glsl-generate [OPTIONS] DONORS REFERENCES NUM_VARIANTS GLSL_VERSION PREFIX OUTPUT_FOLDER`
 
-glsl-generate mutates some reference GLSL shaders to produce families of variant
-shaders.
+
+## Description
+
+glsl-generate takes two directories of GLSL shaders, `DONORS` and `REFERENCES`,
+and mutates the shaders in `REFERENCES` to produce families of variant
+shaders to `OUTPUT_FOLDER`.
+
+Each shader is provided (and output)
+as a **shader job** (a `.json` file)
+that represents all shaders and metadata needed to
+render an image.
+However, the common use-case
+is for each input shader to be a fragment shader, e.g. `shader.frag`,
+with a corresponding JSON file, `shader.json`, alongside.
+The JSON file can either contain `{}` or a dictionary of uniform values.
+See below for more details on shader jobs.
+
+`DONORS` is a corpus of shaders; code from these is injected into the `REFERENCES`.
+
+Each output shader family will have `NUM_VARIANTS` variant shaders, plus
+the original reference shader from which they are derived.
+
+`GLSL_VERSION` specifies the version of GLSL, such as `100` or `"310 es"`.
+
+Each shader family will be output to a directory starting with `OUTPUT_FOLDER/PREFIX_*`.
 
 ## Options
 
@@ -62,38 +85,116 @@ optional arguments:
 
 ## Example
 
-From the graphicsfuzz-1.0 directory:
+Assuming you have extracted the `graphicsfuzz-1.0.zip` file to get `graphicsfuzz-1.0/`:
 
-```shell
-mkdir generated
-glsl-generate shaders/src/main/glsl/samples/donors shaders/src/main/glsl/samples/310es 2 "310 es" my_prefix generated
+```sh
+# Copy the sample shaders into the current directory:
+cp -r graphicsfuzz-1.0/shaders/samples samples
+
+# Create a work directory to store our generated shader families.
+# The directory structure allows glsl-server
+# to find the shaders later.
+mkdir -p work/shaderfamilies
+
+# Generate several shader families from the set of sample shaders.
+# Synopsis:
+# glsl-generate [options] donors references num_variants glsl_version prefix output_folder
+
+# Generate some GLSL version 300 es shaders.
+glsl-generate --max_bytes 500000 --multi_pass samples/donors samples/300es 10 "300 es" family_300es work/shaderfamilies
+
+# Generate some GLSL version 100 shaders.
+glsl-generate --max_bytes 500000 --multi_pass samples/donors samples/100 10 "100" family_100 work/shaderfamilies
+
+# Generate some "Vulkan-compatible" GLSL version 300 es shaders that can be translated to SPIR-V for Vulkan testing.
+glsl-generate --max_bytes 500000 --multi_pass --generate_uniform_bindings --max_uniforms 10 samples/donors samples/310es 10 "310 es" family_vulkan work/shaderfamilies
+
+# The lines above will take approx. 1-2 minutes each, and will generate a shader family for every
+# shader in samples/300es or samples/100:
+ls work/shaderfamilies
+
+# Output:
+
+# family_100_bubblesort_flag
+# family_100_mandelbrot_blurry
+# family_100_squares
+# family_100_colorgrid_modulo
+# family_100_prefix_sum
+
+# family_300es_bubblesort_flag
+# family_300es_mandelbrot_blurry
+# family_300es_squares
+# family_300es_colorgrid_modulo
+# family_300es_prefix_sum
+
+# family_vulkan_bubblesort_flag
+# family_vulkan_mandelbrot_blurry
+# family_vulkan_squares
+# family_vulkan_colorgrid_modulo
+# family_vulkan_prefix_sum
 ```
 
-Note that the output directory must already exists.
+For this example, each shader family will contain 11 shaders;
+1 for the reference shader, and 10 for the variant shaders:
 
-The above command will produce:
+```sh
+ls work/shaderfamilies/family_100_bubblesort_flag/
 
-```shell
-generated/
-├── my_prefix_bubblesort_flag
-│   ├── infolog.json
-│   ├── reference.frag
-│   ├── reference.json
-│   ├── variant_000.frag
-│   ├── variant_000.json
-│   ├── variant_000.prob
-│   ├── variant_001.frag
-│   ├── variant_001.json
-│   └── variant_001.prob
-├── my_prefix_colorgrid_modulo
-│   ├── infolog.json
-│   ├── reference.frag
-│   ├── reference.json
-│   ├── variant_000.frag
-│   ├── variant_000.json
-│   ├── variant_000.prob
-│   ├── variant_001.frag
-│   ├── variant_001.json
-│   └── variant_001.prob
-[ ... etc ... ]
+# Output:
+
+# infolog.json      variant_001.json  variant_004.json  variant_007.json
+# reference.frag    variant_002.frag  variant_005.frag  variant_008.frag
+# reference.json    variant_002.json  variant_005.json  variant_008.json
+# variant_000.frag  variant_003.frag  variant_006.frag  variant_009.frag
+# variant_000.json  variant_003.json  variant_006.json  variant_009.json
+# variant_001.frag  variant_004.frag  variant_007.frag
 ```
+
+## Shader jobs
+
+Each input is, in fact,
+a JSON file that we refer to as a
+**shader job** that
+represents all shaders and metadata needed to
+render an image.
+However,
+our well-tested use-case is
+a shader job that contains a fragment shader
+and a set of uniform values.
+Our worker applications that are used to render a frame
+can only set uniforms
+(they cannot set textures, etc.).
+
+For example, from our release zip:
+
+`graphicsfuzz-1.0/samples/300es/squares.json`:
+
+```json
+{
+  "time": {
+    "func": "glUniform1f",
+    "args": [
+      0.0
+    ]
+  },
+  "mouse": {
+    "func": "glUniform2f",
+    "args": [
+      0.0,
+      0.0
+    ]
+  },
+  "resolution": {
+    "func": "glUniform2f",
+    "args": [
+      256.0,
+      256.0
+    ]
+  }
+}
+```
+
+The fragment shader file for this shader job
+must have the same name and be alongside the shader job file
+with a `.frag` extension;
+in this case, at `graphicsfuzz-1.0/samples/300es/squares.frag`.
diff --git a/docs/glsl-fuzz-intro.md b/docs/glsl-fuzz-intro.md
index 962408449..8794e0fd2 100644
--- a/docs/glsl-fuzz-intro.md
+++ b/docs/glsl-fuzz-intro.md
@@ -4,7 +4,9 @@
 
 ## The problem
 
-A graphics driver takes a *shader program* as input and executes it on a GPU (graphics processing unit) to render an image.
+A graphics driver takes one or more *shaders* as input and executes them on a GPU (graphics processing unit) to render an image.
+Shaders are typically written in a C-like language,
+such as GLSL.
 
 ![shader program, to GPU, to image](images/shader-gpu-image.png)
 
@@ -40,7 +42,7 @@ Finding bugs is not the end of the story: a variant shader that exposes a bug is
 
 Fortunately, our reducer is able to selectively reverse those transformations that are not relevant to the bug. After reduction, we obtain a small difference sufficient to expose the driver issue.
 
-![The same source code, the majority of which is highlighted in yellow and striked out, but parts of one statement remain.](images/variant-reduced.png)
+![The same source code, the majority of which is highlighted in yellow and struck out, but parts of one statement remain.](images/variant-reduced.png)
 
 The reduced variant *still exposes the bug*, and differs from the reference only slightly: this is a great starting point to isolate the root cause of the bug in the graphics driver.
 
@@ -48,4 +50,4 @@ The reduced variant *still exposes the bug*, and differs from the reference only
 
 GraphicsFuzz finds bugs in graphics drivers by rendering families of semantically equivalent shaders, and looking for output discrepancies. This approach is known as *metamorphic testing*. For each bug, the reducer saves a lot of debugging time by producing a simpler *minimal-difference test case* that still exposes the bug.
 
-To learn more, checkout the [walkthrough](glsl-fuzz-walkthrough.md), [test genrator manual](glsl-fuzz-generate.md) and [test reducer manual](glsl-fuzz-reduce.md).
\ No newline at end of file
+To learn more, check out the [walkthrough](glsl-fuzz-walkthrough.md).
diff --git a/docs/glsl-fuzz-reduce.md b/docs/glsl-fuzz-reduce.md
index 8d3bfbaac..d9e4eae37 100644
--- a/docs/glsl-fuzz-reduce.md
+++ b/docs/glsl-fuzz-reduce.md
@@ -16,7 +16,7 @@ See below for common examples.
 glsl-reduce takes a *shader job* `SHADER_JOB` (a .json file) as an argument
 as well as further arguments or options to specify the interestingness test.
 glsl-reduce will try to simplify the given shader job to a smaller,
-simpler shader job for that is still deemed "interesting".
+simpler shader job that is still deemed "interesting".
 
 `SHADER_JOB` should be a `.json` shader job file that represents all shaders and metadata needed to
 render an image. If the shader job is named `foo.json`,
@@ -40,7 +40,7 @@ a shader job is interesting if it does *not* produce an
 image and, optionally, the run log from running the shader job includes the
 regular expression `ERROR`.
 This reduction kind is typically used **without** `--preserve-semantics`,
-so the the reducer can change the semantics of the shader;
+so the reducer can change the semantics of the shader;
 we are usually reducing a crash or incorrect shader compilation error,
 so changing the semantics of the shaders is fine, as they should still compile and run.
 Note that the reducer always produces valid shaders that should compile.
@@ -69,7 +69,7 @@ by glsl-generate.
 
 Options:
 
-```sh
+```
 
 Reduce GLSL shaders, driven by a criterion of interest.
 
diff --git a/docs/glsl-fuzz-walkthrough.md b/docs/glsl-fuzz-walkthrough.md
index 560dd2e28..e0b1caa78 100644
--- a/docs/glsl-fuzz-walkthrough.md
+++ b/docs/glsl-fuzz-walkthrough.md
@@ -5,6 +5,24 @@ by generating, running, and reducing GLSL shaders.
 
 In this walkthrough, we will briefly demonstrate most features of glsl-fuzz from start to finish, including our browser-based UI.
 
+The use of `glsl-fuzz` can be roughly split into the following steps:
+
+* **Generate some shaders** using `glsl-generate` on your desktop.
+* **Run the shaders** using `glsl-server` on your desktop 
+ and our *worker applications* on the devices you wish to test, such as Android devices.
+* **Reduce the buggy shaders**, again using `glsl-server` on your desktop
+and our *worker applications* on your devices.
+Internally, `glsl-server` calls the command line reducer tool
+`glsl-reduce`.
+
+The `glsl-generate` and `glsl-reduce` tools can be used
+stand-alone, without the `glsl-server` tool and worker applications,
+but we focus on using our entire set of tools 
+in this walkthrough.
+
+
+## Requirements
+
 We will be using the latest release zip `graphicsfuzz-1.0.zip` and worker applications.
 You can download these from the [releases page](glsl-fuzz-releases.md)
 or [build them from source](glsl-fuzz-build.md).
@@ -19,13 +37,13 @@ Add the following directories to your path:
   * `graphicsfuzz-1.0/bin/Mac`
   * `graphicsfuzz-1.0/bin/Windows`
 
-The `graphicsfuzz-1.0/` directory is the unzipped graphicsfuzz release.
+The `graphicsfuzz-1.0/` directory is the unzipped release.
 If building from source, this directory can be found at `graphicsfuzz/target/graphicsfuzz-1.0/`.
 
 You will also need to install the latest version of the Java 8 Development Kit,
 either:
 
-* From your system's package manager. E.g. `sudo apt-get install openjdk-8-jdk`.
+* From your system's package manager. E.g. Linux: `sudo apt-get install openjdk-8-jdk`.
 * By [downloading and installing Oracle's binary distribution](http://www.oracle.com/technetwork/java/javase/downloads/index.html) (look for Java SE 8uXXX then the JDK link).
 * By downloading and installing some other OpenJDK binary distribution for your platform.
 
@@ -45,17 +63,64 @@ GraphicsFuzz works by taking a *reference shader* and producing a family of *var
 The reference shader and its variants together are referred to as a *shader family*.
 
 The `glsl-generate` tool generates shader families. The inputs are a folder of reference shaders
-and a folder of *donor shaders* (not pictured above). In theory, these input shaders can be any GLSL fragment shaders. In practice, we designed our tools to support shaders from glslsandbox.com, and so we currently only support shaders with uniforms as inputs (and the values for these will be fixed).
-Each shader file `shader.frag` must have a corresponding `shader.json` metadata file alongside it, which contains the values for the uniforms.
+and a folder of *donor shaders* (not pictured above).
+
+> The *donor shaders* are a corpus of shaders;
+> `glsl-generate` will copy chunks of code from the donor shaders
+> into each generated shader.
+
+Although `glsl-generate` supports
+GLSL fragment, vertex, and compute shaders,
+our well-tested use-case is fragment shaders
+that only use uniforms as inputs,
+and our worker applications can only set uniforms
+(they cannot set textures, etc.).
+Thus,
+we will focus on this use-case for the walkthrough.
+
+Each fragment shader input is, in fact,
+a JSON file that we refer to as a
+**shader job**.
+This file contains the set of uniforms (and their values)
+that will be set;
+[we discuss the format of the JSON file in more detail below](#format-of-json-files).
+For example, from our release zip:
+
+`graphicsfuzz-1.0/samples/300es/squares.json`:
+
+```json
+{
+  "time": {
+    "func": "glUniform1f",
+    "args": [
+      0.0
+    ]
+  },
+  "mouse": {
+    "func": "glUniform2f",
+    "args": [
+      0.0,
+      0.0
+    ]
+  },
+  "resolution": {
+    "func": "glUniform2f",
+    "args": [
+      256.0,
+      256.0
+    ]
+  }
+}
+```
 
-> In fact, we refer to the `shader.json` as the **shader job**;
-> in general, there can be `shader.frag`, `shader.vert`, and/or `shader.compute` alongside
-> this file, so we treat `shader.json` as the input file that represents all shaders
-> and metadata necessary for rendering an image.
-> Thus, the inputs are really a set of shader jobs,
-> but in this walkthrough, each shader job will just have an associated fragment shader.
+The fragment shader file for this shader job
+must have the same name and be alongside the shader job file
+with a `.frag` extension;
+in this case, at `graphicsfuzz-1.0/samples/300es/squares.frag`.
+Thus, the inputs and outputs for `glsl-generate` are actually
+folders of shader jobs.
 
-We can create some shader families as follows:
+We can create some shader families from our provided sample shader jobs as follows:
 
 ```sh
 # Copy the sample shaders into the current directory:
@@ -108,24 +173,21 @@ Each shader family contains 11 shader jobs;
 1 for the reference shader, and 10 for the variant shaders:
 
 ```sh
-ls work/shaderfamilies/family_100_bubblesort_flag/*.json
+ls work/shaderfamilies/family_100_bubblesort_flag/
 
 # Output:
 
-# infolog.json      variant_002.frag  variant_005.frag  variant_008.frag
-# reference.frag    variant_002.json  variant_005.json  variant_008.json
-# reference.json    variant_002.prob  variant_005.prob  variant_008.prob
+# infolog.json      variant_001.json  variant_004.json  variant_007.json
+# reference.frag    variant_002.frag  variant_005.frag  variant_008.frag
+# reference.json    variant_002.json  variant_005.json  variant_008.json
 # variant_000.frag  variant_003.frag  variant_006.frag  variant_009.frag
 # variant_000.json  variant_003.json  variant_006.json  variant_009.json
-# variant_000.prob  variant_003.prob  variant_006.prob  variant_009.prob
 # variant_001.frag  variant_004.frag  variant_007.frag
-# variant_001.json  variant_004.json  variant_007.json
-# variant_001.prob  variant_004.prob  variant_007.prob
 ```
 
-Note that `infolog.json` is not a shader job.
-The `.prob` files give details on the transformations (and their probabilities)
-that were used to generate each shader.
+Note that `infolog.json` is not a shader job;
+it is simply a JSON file containing some metadata about how the
+shader family was generated.
 
 ## Running the server
 
@@ -237,6 +299,16 @@ but the app should then start and the screen will remain
 black with animated text,
 similar to the desktop worker.
 
+> Note that the `gles-worker-android` app may crash a lot,
+> and it will automatically restart;
+> this is usually because the graphics driver crashed when running
+> a complex shader.
+> However, it may terminate intentionally if it detects any errors,
+> such as when the network connection between the worker and server
+> fails.
+> The crash-happy approach is a self-defense mechanism to try
+> to ensure that we return to a good state before continuing.
+
 > To exit the app, you **must use the back button**, otherwise it will automatically restart.
 
 The app should show a dialogue where you can enter the URL of the server.
@@ -308,9 +380,14 @@ adb shell pm grant com.graphicsfuzz.vkworker android.permission.WRITE_EXTERNAL_S
 # and the serial number of the Android device (found using `adb devices`).
 # Add `--help` to see options
 # Add `--server` to specify a server URL (default is http://localhost:8080)
+# Add `--spirvopt=-O` to run `spirv-opt -O` on every shader.  
 glsl-to-spv-worker galaxy-s9-vulkan --adbID 21372144e90c7fae
 ```
 
+Note that running `spirv-opt` on each shader by adding the `--spirvopt=ARGS` argument
+can help find additional bugs that would otherwise not be found.
+This approach can also find bugs in `spirv-opt` itself.
+
 You should see `No job` repeatedly output to the terminal.
 
 If you see `Cannot connect to server`
@@ -388,6 +465,15 @@ The default reduction settings are sufficient, so just click
 "Start reduction".
 
 Once again, you should see the worker application rendering images.
+
+> Note that the server will not progress with the reduction until
+> all prior work for the specified worker has finished.
+> Thus, if you previously queued a large number of shader families
+> to this worker,
+> they will continue to run before the reduction starts executing
+> on the worker. You can kill and restart the server to clear its
+> work queues.
+
 Once the reduction has finished,
 refresh the page and you should see the result:
 
@@ -518,7 +604,7 @@ In fact, the "reduction log" shown by the WebUI
 includes the command that was run on its first line.
 E.g.
 
-`glsl-reduce shaderfamilies/familiy01/variant_01.json --reduction-kind [etc.]`
+`glsl-reduce shaderfamilies/family01/variant_01.json --reduction-kind [etc.]`
 
 > You can try running these commands from the command line in the `work`
 > directory, although note that some "empty" arguments (i.e. "")
@@ -636,3 +722,26 @@ to the server.
 ### Additional options
 
 See the [glsl-reduce manual](glsl-fuzz-reduce.md) for details on other options.
+
+## Format of JSON files
+
+As described above, a shader job is identified by a JSON file.  This file can be used to specify concrete values for uniforms used by the associated shaders.
+
+The file should contain a single dictionary of uniform value entries.
+
+Here is an example uniform value entry:
+
+```
+  "iDate": {
+    "func": "glUniform4f",
+    "args": [
+      2016.0,
+      9.0,
+      22.0,
+      61200.0
+    ],
+    "binding": 5
+  }
+```
+
+The key, `iDate`, is the name of the uniform.  This maps to a sub-dictionary specifying: via `func` the OpenGL function used to set the uniform (`glUniform4f` in this case, corresponding to a `vec4`), via `args` a sequence of values that should be used to populate the uniform (four floating point values in this case), and optionally via `binding` an integer which, if provided, must match the binding of the uniform buffer to which the uniform belongs.
diff --git a/docs/glsl-reduce-walkthrough.md b/docs/glsl-reduce-walkthrough.md
index 8a15564ac..f3b75d97f 100644
--- a/docs/glsl-reduce-walkthrough.md
+++ b/docs/glsl-reduce-walkthrough.md
@@ -65,13 +65,13 @@ cat glsl-reduce-walkthrough/colorgrid_modulo.frag
 # Output:
 # <contents of the original shader>
 
-# Run glsl-reduce
+# Run glsl-reduce, putting the tool's output in the 'reduction_results' directory (created if it does not exist)
 glsl-reduce glsl-reduce-walkthrough/colorgrid_modulo.json ./glsl-reduce-walkthrough/interestingness_test --output reduction_results
 
 # Output:
 # <lots of messages about the reducer's progress>
 
-# Confirm that the reduced fragment shader file still reproduces the issue:
+# Confirm that the reduced fragment shader file still reproduces the issue
 python glsl-reduce-walkthrough/fake_compiler.py reduction_results/colorgrid_modulo_reduced_final.frag
 
 # Output:
@@ -99,6 +99,8 @@ glsl-reduce requires two arguments:
 * a *shader job*: a path to a `.json` file representing the shader or shaders of interest
 * an *interestingness test*: a path to an executable script encoding the properties a shader job must satisfy to be deemed interesting.
 
+It is advisable to also use the `--output` option to specify a directory for generated results; this will be the current directory by default.
+
 The `.json` file serves two purposes: (1) it tells glsl-reduce which shaders to operate on -- if it is called `foo.json` then at least one of `foo.frag`, `foo.vert` and `foo.comp` must be present, and any that are present will be reduced; (2) it allows metadata about these shaders to be stored.  At present, glsl-reduce does not allow any metadata when used in stand-alone mode, so the JSON file is required to simply contain `{}`.  (The file is used for meaningful metadata when glsl-reduce is used in conjunction with [glsl-fuzz](glsl-fuzz-intro.md).)
 
 The *interestingness test* (name inspired by [C-Reduce](https://embed.cs.utah.edu/creduce/using/)) is a script that codifies what it means for a shader to be interesting.  It takes the name of a shader job as an argument, and should return 0 if and only if the shaders associated with the shader job are interesting.  What "interesting" means is specific to the context in which you are using glsl-reduce.
@@ -106,7 +108,7 @@ The *interestingness test* (name inspired by [C-Reduce](https://embed.cs.utah.ed
 In the above example we deemed a shader job `foo.json` to be interesting if the associated fragment shader `foo.frag` caused the fake compiler to fail with the "`too much indexing`" message.  Have a look at `glsl-reduce-walkthrough/interestingness_test.py` (which is invoked by `glsl-reduce-walkthrough/interestingness_test` for Linux/Mac, and the corresponding `.bat` file for Windows): it checks precisely this.
 
 In a different setting we might be interested in reducing with respect to a completely different property, e.g. we might check whether rendering using a given shader causes a device's temperature to exceed some threshold, whether a shader causes a driver to consume more than a certain amount of memory, or whether a shader sends a shader compiler into
-a seemingly infinite loop.  Writing the interestingness test is entirely in the hands of the user of glsl-reduce.
+a seemingly infinite loop.  Writing the interestingness test is entirely in the hands of the user of glsl-reduce.  Notice that in each of these examples, the property we care about (temperature, memory or execution time) is non-binary; it needs to be turned into a binary property by using an appropriate limit on the resource in question inside the interestingness test.
 
 
 # Bug slippage: the need for a strong interestingness test
diff --git a/docs/glsl-reduce.md b/docs/glsl-reduce.md
index e8c02405c..06e5353f8 100644
--- a/docs/glsl-reduce.md
+++ b/docs/glsl-reduce.md
@@ -11,7 +11,7 @@ glsl-reduce [OPTIONS] SHADER_JOB INTERESTINGNESS_TEST
 
 ## Description
 
-glsl-reduce takes a *shader job* `SHADER_JOB`, and an executable script `INTERSTINGNESS_TEST` that takes a shader job as an argument.  `INTERESTINGNESS_TEST` must exit with code 0 when applied to the initial `SHADER_JOB`.  glsl-reduce will then try to simplify the given shader job to a smaller, simpler shader job for which `INTERESTINGESS_TEST` still exits with code 0.
+glsl-reduce takes a *shader job* `SHADER_JOB`, and an executable script `INTERESTINGNESS_TEST` that takes a shader job as an argument.  `INTERESTINGNESS_TEST` must exit with code 0 when applied to the initial `SHADER_JOB`.  glsl-reduce will then try to simplify the given shader job to a smaller, simpler shader job for which `INTERESTINGESS_TEST` still exits with code 0.
 
 `SHADER_JOB` must be a `.json` file containing simply `{}`.  (The role of this file is to provide metadata about shaders when glsl-reduce is used in conjunction with [glsl-fuzz](glsl-fuzz-intro.md).)  If the shader job is named `foo.json`, glsl-reduce will look for corresponding shaders named `foo.frag`, `foo.vert` and `foo.comp`, of which there must be at least one, and will apply reduction to all such shaders that are present.  On termination, the reduced shader job will be named `foo_reduced_final.json` (with associated shader files).
 
diff --git a/fuzzerserver/src/main/java/com/graphicsfuzz/server/FuzzerServiceImpl.java b/fuzzerserver/src/main/java/com/graphicsfuzz/server/FuzzerServiceImpl.java
index 1f0764bbb..a4201a1b6 100644
--- a/fuzzerserver/src/main/java/com/graphicsfuzz/server/FuzzerServiceImpl.java
+++ b/fuzzerserver/src/main/java/com/graphicsfuzz/server/FuzzerServiceImpl.java
@@ -151,7 +151,7 @@ public GetWorkerNameResult getWorkerName(String platformInfo, String oldWorker)
         }
 
       } catch (IOException exception) {
-        LOGGER.info("Failed to read existing platform info.", exception);
+        LOGGER.info("Failed to read existing platform info.");
       }
     }
 
diff --git a/generator/src/main/java/com/graphicsfuzz/generator/tool/Generate.java b/generator/src/main/java/com/graphicsfuzz/generator/tool/Generate.java
index 7e6f651a0..f58911cf2 100755
--- a/generator/src/main/java/com/graphicsfuzz/generator/tool/Generate.java
+++ b/generator/src/main/java/com/graphicsfuzz/generator/tool/Generate.java
@@ -158,6 +158,10 @@ public static void addGeneratorCommonArguments(ArgumentParser parser) {
         .help("Do not generate the injectionSwitch uniform.")
         .action(Arguments.storeTrue());
 
+    // Hidden option; for developer debugging.
+    parser.addArgument("--write_probabilities")
+        .help(Arguments.SUPPRESS)
+        .action(Arguments.storeTrue());
   }
 
   /**
@@ -311,10 +315,12 @@ public static void mainHelper(String[] args)
         variantShaderJob,
         outputShaderJobFile);
 
-    fileOps.writeAdditionalInfo(
-        outputShaderJobFile,
-        ".prob",
-        generationInfo.toString());
+    if (ns.getBoolean("write_probabilities")) {
+      fileOps.writeAdditionalInfo(
+          outputShaderJobFile,
+          ".prob",
+          generationInfo.toString());
+    }
 
   }
 
diff --git a/python/src/main/python/drivers/glsl-to-spv-worker b/python/src/main/python/drivers/glsl-to-spv-worker
new file mode 100644
index 000000000..b805b4d1f
--- /dev/null
+++ b/python/src/main/python/drivers/glsl-to-spv-worker
@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+${BASH_SOURCE}.py "$@"
+
diff --git a/python/src/main/python/drivers/glsl-to-spv-worker.bat b/python/src/main/python/drivers/glsl-to-spv-worker.bat
new file mode 100644
index 000000000..44b64a05e
--- /dev/null
+++ b/python/src/main/python/drivers/glsl-to-spv-worker.bat
@@ -0,0 +1,19 @@
+@echo off
+
+@REM
+@REM  Copyright 2018 The GraphicsFuzz Project Authors
+@REM
+@REM  Licensed under the Apache License, Version 2.0 (the "License");
+@REM  you may not use this file except in compliance with the License.
+@REM  You may obtain a copy of the License at
+@REM
+@REM      https://www.apache.org/licenses/LICENSE-2.0
+@REM
+@REM  Unless required by applicable law or agreed to in writing, software
+@REM  distributed under the License is distributed on an "AS IS" BASIS,
+@REM  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+@REM  See the License for the specific language governing permissions and
+@REM  limitations under the License.
+@REM
+
+python "%~dpn0.py" %*
diff --git a/vulkan-worker/.gitignore b/vulkan-worker/.gitignore
index 8214b4df1..766e0a2c5 100644
--- a/vulkan-worker/.gitignore
+++ b/vulkan-worker/.gitignore
@@ -1,5 +1,6 @@
 build/
 build_*/
+cmake-build-debug/
 local.properties
 gradle.properties
 .externalNativeBuild/