diff --git a/src/devices/graphics/cts-integration.jd b/src/devices/graphics/cts-integration.jd
index c8be6b6..a0571a5 100644
--- a/src/devices/graphics/cts-integration.jd
+++ b/src/devices/graphics/cts-integration.jd
@@ -25,19 +25,20 @@
   </div>
 </div>
 
-<h2 id=deqp_tests_in_android_cts>Deqp tests in Android CTS</h2>
+<p>Android CTS release packages (available from
+<a href="{@docRoot}compatibility/cts/downloads.html">Android Compatibility
+Downloads</a>) include deqp tests and require a subset of these tests (known as
+the <code>mustpass</code> list), to pass. For devices that do not support a
+target API or extension, tests are skipped and reported as passing.</p>
 
-<p>Deqp tests have been part of Android CTS since the Android 5.0 release.</p>
-
-<p>Android CTS requires a certain subset of tests, called the <code>mustpass</code> list, to pass. The <code>mustpass</code> list includes OpenGL ES 3.0, OpenGL ES 3.1, and the Android Extension Pack tests. If a device doesn't support a target API or extension, tests are skipped and reported as passing. 
-The <code>mustpass</code> files can be found under the <code>android/cts</code> directory in the deqp source tree.</p>
-
-<p>Deqp tests are included in the Android CTS release packages, available on the <a href="{@docRoot}compatibility/downloads.html">Android Compatibility Downloads</a> page. </p>
-
-<p>You can run deqp tests through the <code>cts-tradefed</code> utility with the following command:</p>
+<p>The <code>mustpass</code> list includes OpenGL ES 3.0, OpenGL ES
+3.1, OpenGL ES 3.2, and the Android Extension Pack tests. <code>mustpass</code>
+files can be found under the <code>android/cts</code> directory in the deqp
+source tree. You can run deqp tests through the <code>cts-tradefed</code>
+utility with the following command:</p>
 
 <pre>
-cts-tradefed run cts --plan CTS-DEQP
+$ cts-tradefed run cts --plan CTS-DEQP
 </pre>
 
 <h2 id=duplicating_runs_without_cts>Duplicating runs without CTS</h2>
@@ -46,27 +47,23 @@
 following command:</p>
 
 <pre>
-adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e
-cmdLine "deqp --deqp-case=dEQP-GLES3.some_group.*
---deqp-gl-config-name=rgba8888d24s8 --deqp-log-filename=/sdcard/dEQP-Log.qpa
+$ adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
+cmdLine "deqp --deqp-case=dEQP-GLES3.some_group.* --deqp-gl-config-name=rgba8888d24s8 --deqp-log-filename=/sdcard/dEQP-Log.qpa
 </pre>
 
-<p>The important part of that command is the following:</p>
-<pre>
---deqp-gl-config-name=rgba8888d24s8
-</pre>
+<p>The important part is the <code>--deqp-gl-config-name=rgba8888d24s8</code>
+argument, which requests the tests be run on an RGBA 8888 on-screen surface
+with a 24-bit depth buffer and an 8-bit stencil buffer. Remember to set
+the desired tests using the <code>--deqp-case</code> argument.</p>
 
-<p>This argument requests the tests be run on an RGBA 8888 on-screen surface
-with a 24-bit depth buffer and an 8-bit stencil buffer. Also remember to set
-the desired tests, e.g. using the <code>--deqp-case</code> argument.</p>
+<h2 id=mapping_of_the_cts_results>CTS results mapping</h2>
 
-<h2 id=mapping_of_the_cts_results>Mapping of the CTS results</h2>
-
-<p>In the Android CTS, a test case can end up in three states: passed, failed, or
-not executed.</p>
-
-<p>The deqp has more result codes available. A mapping is automatically performed
-by the CTS. The following deqp result codes are mapped to a CTS pass: <code>Pass</code>, <code>NotSupported</code>, <code>QualityWarning</code>, and <code>CompatibilityWarning</code> </p>
-
-<p>The following results are interpreted as a CTS failure:
-<code>Fail</code>, <code>ResourceError</code>, <code>Crash</code>, <code>Timeout</code>, and <code>InternalError</code></p>
+<p>In the Android CTS, a test case can end up in one of three states: passed,
+failed, or not executed (the deqp has more result codes available). CTS
+automatically maps deqp result codes to CTS results:</p>
+<ul>
+<li>A CTS pass can include <code>Pass</code>, <code>NotSupported</code>,
+<code>QualityWarning</code>, and <code>CompatibilityWarning</code>.</li>
+<li>A CTS failure can include <code>Fail</code>, <code>ResourceError</code>,
+<code>Crash</code>, <code>Timeout</code>, and <code>InternalError</code>.</li>
+</ul>
diff --git a/src/devices/graphics/run-tests.jd b/src/devices/graphics/run-tests.jd
index 3da7b31..d08dd35 100644
--- a/src/devices/graphics/run-tests.jd
+++ b/src/devices/graphics/run-tests.jd
@@ -24,11 +24,13 @@
     </ol>
   </div>
 </div>
-
+<p>This page provides instructions for running deqp tests in Linux and Windows
+environments, using command line arguments, and working with the Android
+application package.</p>
 
 <h2 id=linux_and_windows_environments>Linux and Windows environments</h2>
 
-<p>The following files and directories must be copied to the target.</p>
+<p>Start by copying the following files and directories to the target.</p>
 
 <table>
  <tr>
@@ -38,59 +40,78 @@
  </tr>
 
  <tr>
-    <td><p>Execution Server</p></td>
+    <td>Execution Server</td>
     <td><code>build/execserver/execserver</code></td>
-    <td><code>&lt;dst>/execserver</code></td>
+    <td><code>&lt;dst&gt;/execserver</code></td>
  </tr>
- 
+
  <tr>
-    <td><p>EGL Module</p></td>
+    <td>EGL Module</td>
     <td><code>build/modules/egl/deqp-egl</code></td>
-    <td><code>&lt;dst>/deqp-egl</code></td>
+    <td><code>&lt;dst&gt;/deqp-egl</code></td>
  </tr>
- 
+
  <tr>
-    <td><p>GLES2 Module</p></td>
-    <td><code>build/modules/gles2/deqp-gles2data/gles2</code></td>
-    <td>
-    <code>
-&lt;dst>/deqp-gles2<br/>
-&lt;dst>/gles2
-    </code>
-    </td>
+    <td rowspan=2 style="vertical-align:middle">GLES2 Module</td>
+    <td><code>build/modules/gles2/deqp-gles2</code></td>
+    <td><code>&lt;dst&gt;/deqp-gles2</code></td>
  </tr>
- 
+
+
  <tr>
-    <td><p>GLES3 Module</p></td>
-    <td><code>build/modules/gles3/deqp-gles3data/gles3</code></td>
-    <td>
-    <code>
-&lt;dst>/deqp-gles3<br/>
-&lt;dst>/gles3
-</code>
-</td>
+    <td><code>data/gles2</code></td>
+    <td><code>&lt;dst&gt;/gles2</code></td>
  </tr>
- 
+
+
+
  <tr>
-    <td><p>GLES3.1 Module</p></td>
-    <td><code>build/modules/gles31/deqp-gles31data/gles31</code></td>
-    <td>
-    <code>
-&lt;dst>/deqp-gles31<br/>
-&lt;dst>/gles31
-    </code>
-    </td>
+    <td rowspan=2 style="vertical-align:middle">GLES3 Module</td>
+    <td><code>build/modules/gles3/deqp-gles3</td>
+    <td><code>&lt;dst&gt;/deqp-gles3</code></td>
  </tr>
+
+ <tr>
+    <td><code>data/gles3</code></td>
+    <td><code>&lt;dst&gt;/gles3</code></td>
+ </tr>
+
+ <tr>
+    <td rowspan=2 style="vertical-align:middle">GLES3.1 Module</td>
+    <td><code>build/modules/gles31/deqp-gles31</code></td>
+    <td><code>&lt;dst&gt;/deqp-gles31</code></td>
+ </tr>
+
+ <tr>
+    <td><code>data/gles31</code></td>
+    <td><code>&lt;dst&gt;/gles31</code></td>
+ </tr>
+
+
+  <tr>
+    <td rowspan=2 style="vertical-align:middle">GLES3.2 Module</td>
+    <td><code>build/modules/gles32/deqp-gles32</code></td>
+    <td><code>&lt;dst&gt;/deqp-gles32</code></td>
+ </tr>
+
+  <tr>
+    <td><code>data/gles32</code></td>
+    <td><code>&lt;dst&gt;/gles32</code></td>
+ </tr>
+
 </table>
 
-<p>Execution service and test binaries can be deployed anywhere in the target file system. Test binaries expect to find data directories in the current working directory.</p>
-
-<p>Start the Test Execution Service on the target device. For more details on
-starting the service, see <a href="port-tests.html#test_execution_service">Test execution service</a>.</p>
+<p>You can deploy the execution service and test binaries anywhere in the target
+file system; however, test binaries expect to find data directories in the
+current working directory. When ready, start the Test Execution Service on the
+target device. For details on starting the service, see
+<a href="{@docRoot}devices/graphics/port-tests.html#test_execution_service">Test
+execution service</a>.</p>
 
 <h2 id=command_line_arguments>Command line arguments</h2>
 
-<p>The following table lists command line arguments that affect execution of all test programs. </p>
+<p>The following table lists command line arguments that affect execution of all
+test programs.</p>
 
 <table width="100%">
 <col style="width:50%">
@@ -101,42 +122,32 @@
  </tr>
 
  <tr>
-    <td><code>
---deqp-case=&lt;casename></code></td>
-<td><p>Run cases that match a given pattern. Wildcard (*) is supported.</p>
-</td>
- </tr>
- 
- <tr>
-    <td><code>
---deqp-log-filename=&lt;filename></code></td>
-<td><p>Write test results to the file whose name you provide. </p>
-<p>The test execution service will set the filename when starting a test.</p>
-</td>
+<td><code>--deqp-case=&lt;casename&gt;</code></td>
+<td>Run cases that match a given pattern. Wildcard (*) is supported.</td>
  </tr>
 
  <tr>
- <td><code>
---deqp-stdin-caselist<br/>
---deqp-caselist=&lt;caselist><br/>
---deqp-caselist-file=&lt;filename></code></td>
-<td><p>Read case list from stdin or from a given argument. The test execution service
-will set the argument according to the execution request received. See the next
-section for a description of the case list format.</p>
-</td>
+<td><code>--deqp-log-filename=&lt;filename&gt;</code></td>
+<td>Write test results to the file whose name you provide. The test execution
+service will set the filename when starting a test.</td>
+ </tr>
+
+ <tr>
+ <td><code>--deqp-stdin-caselist<br/>
+--deqp-caselist=&lt;caselist&gt;<br/>
+--deqp-caselist-file=&lt;filename&gt;</code></td>
+<td>Read case list from stdin or from a given argument. The test execution
+service will set the argument according to the execution request received. See
+the next section for a description of the case list format.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-test-iteration-count=&lt;count></code></td>
-<td><p>Override iteration count for tests that support a variable number of
-iterations. </p>
-</td>
+<td><code>--deqp-test-iteration-count=&lt;count&gt;</code></td>
+<td>Override iteration count for tests that support a variable number of
+iterations.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-base-seed=&lt;seed></code></td>
-<td><p>Base seed for the test cases that use randomization.</p>
-</td>
+    <td><code>--deqp-base-seed=&lt;seed&gt;</code></td>
+    <td>Base seed for the test cases that use randomization.</td>
  </tr>
 </table>
 
@@ -153,72 +164,64 @@
    <th>Description</th>
  </tr>
  <tr>
-    <td><code>
---deqp-gl-context-type=&lt;type></code></td>
-<td><p>OpenGL context type. Available context types depend on the platform. On
-platforms supporting EGL, the value <code>egl</code> can be used to select the EGL context.</p>
-</td>
+    <td><code>--deqp-gl-context-type=&lt;type&gt;</code></td>
+    <td>OpenGL context type. Available context types depend on the platform. On
+    platforms supporting EGL, the value <code>egl</code> can be used to select
+    the EGL context.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-gl-config-id=&lt;id></code></td>
-<td><p>Run tests for the provided GL configuration ID. Interpretation is
-platform-dependent. On the EGL platform, this is the EGL configuration ID.</p>
-</td>
+    <td><code>--deqp-gl-config-id=&lt;id&gt;</code></td>
+    <td>Run tests for the provided GL configuration ID. Interpretation is
+    platform-dependent. On the EGL platform, this is the EGL configuration ID.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-gl-config-name=&lt;name></code></td>
-<td><p>Run tests for a named GL configuration. Interpretation is platform-dependent.
-For EGL, the format is <code>rgb(a)&lt;bits&gt;d&lt;bits&gt;s&lt;bits&gt;</code>. For example, a value of <code>rgb888s8</code> will select the first configuration where the color buffer is RGB888 and the
-stencil buffer has 8 bits.</p>
-</td>
+    <td><code>--deqp-gl-config-name=&lt;name&gt;</code></td>
+    <td><p>Run tests for a named GL configuration. Interpretation is
+    platform-dependent. For EGL, the format is
+    <code>rgb(a)&lt;bits&gt;d&lt;bits&gt;s&lt;bits&gt;</code>. For example, a
+    value of <code>rgb888s8</code> will select the first configuration where the
+    color buffer is RGB888 and the stencil buffer has 8 bits.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-gl-context-flags=&lt;flags></code></td>
-<td><p>Creates a context. Specify <code>robust</code> or <code>debug</code>.</p>
-</td>
+    <td><code>--deqp-gl-context-flags=&lt;flags&gt;</code></td>
+    <td>Creates a context. Specify <code>robust</code> or <code>debug</code>.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-surface-width=&lt;width><br/>
---deqp-surface-height=&lt;height></code></td>
-<td><p>Try to create a surface with a given size. Support for this is optional.</p>
-</td>
+    <td><code>--deqp-surface-width=&lt;width&gt;<br/>
+    --deqp-surface-height=&lt;height&gt;</code></td>
+    <td>Try to create a surface with a given size. Support for this is optional.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-surface-type=&lt;type></code></td>
-<td><p>Use a given surface type as the main test rendering target. Possible types are <code>window</code>, <code>pixmap</code>, <code>pbuffer</code>, and <code>fbo</code>.</p>
-</td>
+    <td><code>--deqp-surface-type=&lt;type&gt;</code></td>
+    <td>Use a given surface type as the main test rendering target. Possible
+    types are <code>window</code>, <code>pixmap</code>, <code>pbuffer</code>,
+    and <code>fbo</code>.</td>
  </tr>
  <tr>
-    <td><code>
---deqp-screen-rotation=&lt;rotation></code></td>
-<td><p>Screen orientation in increments of 90 degrees for platforms that support it.</p>
-</td>
+    <td><code>--deqp-screen-rotation=&lt;rotation&gt;</code></td>
+    <td>Screen orientation in increments of 90 degrees for platforms that
+    support it.</td>
  </tr>
 </table>
 
 <h3 id=test_case_list_format>Test case list format</h3>
 
-<p>The test case list can be given in two formats. The first option is to list the
-full name of each test on a separate line in a standard ASCII file. As the test
-sets grow, the repetitive prefixes can be cumbersome. To avoid repeating the
-prefixes, use a trie (also known as a prefix tree) syntax shown below.</p>
+<p>The test case list can be given in two formats. The first option is to list
+the full name of each test on a separate line in a standard ASCII file. As the
+test sets grow, the repetitive prefixes can be cumbersome. To avoid repeating
+the prefixes, use a trie (also known as a prefix tree) syntax shown below.</p>
 
 <pre>
 {nodeName{firstChild{…},…lastChild{…}}}
 </pre>
 
-<p>For example, please review the following:</p>
+<p>For example:</p>
 
 <pre>
 {dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
 </pre>
 
-<p>That list would translate into two test cases:</p>
+<p>Translates into the following two test cases:</p>
 
 <pre>
 dEQP-EGL.config_list
@@ -227,41 +230,47 @@
 
 <h2 id=android>Android</h2>
 
-<p>The Android application package contains everything required, including the
-test execution service, test binaries, and data files. The test activity is a <code>NativeActivity </code>and it uses EGL, which requires Android 3.2 or later.</p>
+<p>The Android application package contains all required components, including
+the test execution service, test binaries, and data files. The test activity is
+a <code>NativeActivity</code> that uses EGL (requires Android 3.2 or higher).</p>
 
-<p>The application package can be installed with the following command. The name shown is the name of the APK in the Android CTS package. The name depends on the build:</p>
-<pre>
-adb –d install –r com.drawelements.deqp.apk
-</pre>
+<p>The application package can be installed with the following command (name
+shown is the name of the APK in the Android CTS package; which name depends on
+the build):</p>
+<pre>$ adb –d install –r com.drawelements.deqp.apk</pre>
 
 <p>To launch the test execution service and to setup port forwarding, use the
 following:</p>
 <pre>
-adb –d forward tcp:50016 tcp:50016
-adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
+$ adb –d forward tcp:50016 tcp:50016
+$ adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
 </pre>
 
 <p>Debug prints can be enabled by executing the following before starting the
 tests:</p>
+
 <pre>
-adb –d shell setprop log.tag.dEQP DEBUG 
+$ adb –d shell setprop log.tag.dEQP DEBUG
 </pre>
 
-<h3 id=executing_tests_on_android_without_android_cts>Executing tests on Android without Android CTS</h3>
+<h3 id=executing_tests_on_android_without_android_cts>Executing tests on
+Android without Android CTS</h3>
 
-<p>If you want to manually start the test execution activity, construct an Android
-intent that targets <code>android.app.NativeActivity</code>. The activities can be found in the <code>com.drawelements.deqp</code> package. The command line must be supplied as an extra string with key <code>"cmdLine"</code> in the Intent.</p>
+<p>To manually start the test execution activity, construct an Android intent
+that targets <code>android.app.NativeActivity</code>. The activities can be
+found in the <code>com.drawelements.deqp</code> package. The command line must
+be supplied as an extra string with key <code>"cmdLine"</code> in the Intent.</p>
 
-<p>A test log will be written to <code>/sdcard/dEQP-log.qpa</code>. If the test run does not start normally, additional debug information is
-available in the device log.</p>
+<p>A test log is written to <code>/sdcard/dEQP-log.qpa</code>. If the test run
+does not start normally, additional debug information is available in the device
+log.</p>
 
-<p>The activity can be launched from the command line using the <code>"am"</code> utility. For example, to run <code>dEQP-GLES2.info</code> tests on a platform supporting <code>NativeActivity,</code> the following command can be used:</p>
+<p>You can launch an activity from the command line using the <code>am</code>
+utility. For example, to run <code>dEQP-GLES2.info</code> tests on a platform
+supporting <code>NativeActivity,</code> use the following commands.</p>
 
-<pre>
-adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e
-cmdLine "deqp --deqp-case=dEQP-GLES2.info.*
---deqp-log-filename=/sdcard/dEQP-Log.qpa
+<pre>$ adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
+cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa
 </pre>
 
 <h3 id=debugging_on_android>Debugging on Android</h3>
@@ -270,48 +279,39 @@
 the debug build by running the following two scripts:</p>
 
 <pre>
-python android/scripts/build.py --native-build-type=Debug
-python android/scripts/install.py
+$ python android/scripts/build.py --native-build-type=Debug
+$ python android/scripts/install.py
 </pre>
 
-<p>After the debug build is installed on the device, to launch the tests under GDB
-running on the host, run the following command:</p>
+<p>After the debug build is installed on the device, to launch the tests under
+GDB running on the host, run the following command:</p>
 
-<pre>
-python android/scripts/debug.py
---deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa
---deqp-case=dEQP-GLES2.functional.*"
+<pre>$ python android/scripts/debug.py \
+--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
 </pre>
 
-<p>The deqp command line will depend on test cases to be executed and other
-required parameters. The script will add a default breakpoint into the
-beginning of the deqp execution (<code>tcu::App::App</code>).</p>
+<p>The deqp command line depends on the test cases to be executed and other
+required parameters. The script adds a default breakpoint at the beginning of
+the deqp execution (<code>tcu::App::App</code>).</p>
 
-<p>The <code>debug.py </code>script accepts multiple command line arguments, e.g. for the following:</p>
+<p>The <code>debug.py</code> script accepts multiple command line arguments for
+actions such as setting breakpoints for debugging, gdbserver connection
+parameters, and paths to additional binaries to debug (use <code>debug.py
+--help</code> for all arguments and explanations). The script also copies some
+default libraries from the target device to get symbol listings.</p>
 
-<ul>
-  <li> Setting the breakpoints for debugging
-  <li> gdbserver connection parameters
-  <li> Paths to additional binaries to debug  
-</ul>
+<p>To step through driver code (such as when the GDB needs to know the locations
+of the binaries with full debug information), add more libraries via
+<code>debug.py</code> command line parameters. This script writes out a
+configuration file for the GDB starting from line 132 of the script file. You
+can provide additional paths to binaries, etc., but supplying correct command
+line parameters should be enough.</p>
 
-<p>Running <code>debug.py --help</code> will list all command line parameters, with explanations.</p>
+<p class="note"><strong>Note:</strong> On Windows, the GDB binary requires
+<code>libpython2.7.dll</code>. Before launching <code>debug.py</code>, add
+<code>&lt;path-to-ndk&gt;/prebuilt/windows/bin</code> to the PATH variable.</p>
 
-<p>The script copies some default libraries from the target device to get symbol
-listings. </p>
-
-<p>If there is a need to step through driver code, more libraries can be added via <code>debug.py</code> command line parameters. This would be applicable, for
-example, if the GDB needs to know the locations of the binaries with full debug
-information. The <code>debug.py</code> script writes out a configuration file for the GDB starting from line 132 of
-the script file. Additional paths to binaries, etc., can be added there, but
-supplying correct command line parameters should be enough.</p>
-
-<p><strong>Notes:</strong></p>
-
-<ul>
-  <li> On Windows, the gdb binary requires <code>libpython2.7.dll</code>. Add
-<code>&lt;path to ndk&gt;/prebuilt/windows/bin</code> to the PATH variable before launching <code>debug.py</code>.
-  <li> Native code debugging does not work on stock Android 4.3. See the Android bug
-report below for suggested workarounds. The bug has been fixed in Android 4.4;
-see the following: <a href="https://code.google.com/p/android/issues/detail?id=58373">https://code.google.com/p/android/issues/detail?id=58373</a>
-</ul>
+<p class="note"><strong>Note:</strong> Native code debugging does not work on
+stock Android 4.3; for workarounds, refer to
+<a href="https://code.google.com/p/android/issues/detail?id=58373">https://code.google.com/p/android/issues/detail?id=58373</a>.
+Android 4.4 and higher do not contain this bug.</p>
diff --git a/src/devices/graphics/testing.jd b/src/devices/graphics/testing.jd
index 56f4495..32db08b 100644
--- a/src/devices/graphics/testing.jd
+++ b/src/devices/graphics/testing.jd
@@ -26,29 +26,46 @@
 </div>
 
 
-<p>This page provides an overview of the GPU testing suite
-called deqp (drawElements Quality Program).</p>
+<p>AOSP includes the drawElements Quality Program (deqp) GPU testing suite at
+<a href="https://android.googlesource.com/platform/external/deqp">https://android.googlesource.com/platform/external/deqp</a>.
+</p>
 
-<p>You can access the code for deqp in AOSP at the following location: <a href="https://android.googlesource.com/platform/external/deqp">https://android.googlesource.com/platform/external/deqp</a></p>
-
-<p>To work with the latest submitted code, use the <code>deqp-dev</code> branch. If you want the code that matches the Android 5.0 CTS release, use the <code>lollipop-release</code> branch. </p>
+<p>To work with the latest submitted code, use the
+<code>deqp-dev</code> branch. For code that matches a specific Android CTS
+release, use the <code><em>release-code-name</em>-release</code> branch (e.g.
+for Android 6.0, use the <code>marshmallow-release</code> branch).</p>
 
 <h2 id=deploying_deqp>Deploying deqp</h2>
 
-<p>To deploy the deqp test suite to a new environment, please review the deqp information regarding the following: </p>
-   
+<p>To deploy the deqp test suite to a new environment, review all pages in this
+section:</p>
 <ul>
-  <li>Building test programs
-  <li>Porting the test framework (optional, depending on the target platform)
-  <li>Running the tests 
-  <li>Automating the tests 
-  <li>Using special test groups 
-  <li>Integrating with Android CTS
+<li><a href="{@docRoot}devices/graphics/build-tests.html">Building test
+programs</a>. Discusses build systems such as CMake, targets, and various builds
+(Win32, Android, Linux).</li>
+<li><a href="{@docRoot}devices/graphics/port-tests.html">Porting the test
+framework</a>. Describes adapting base portability libraries, implementing
+test-framework platform-integration interfaces, and porting the
+execution service. Porting is optional (depending on the target platform).</li>
+<li><a href="{@docRoot}devices/graphics/run-tests.html">Running the tests</a>.
+Provides instructions for running deqp tests in Linux and Windows environments,
+command line arguments, and the Android package.</li>
+<li><a href="{@docRoot}devices/graphics/automate-tests.html">Automating the
+tests</a>. Covers test automation options, command line tools, CSV and XML
+exporting, and conversion to JUnit.</li>
+<li><a href="{@docRoot}devices/graphics/test-groups.html">Using special test
+groups</a>. Provides advice for running memory allocation and long-running
+stress tests.</li>
+<li><a href="{@docRoot}devices/graphics/cts-integration.html">Integrating with
+Android CTS</a>. Describes the <code>mustpass</code> list of tests, duplicating
+runs, and mapping CTS results.</li>
 </ul>
 
 <h2 id=source_layout>Source layout</h2>
 
-<p>The source code layout for the deqp test modules and supporting libraries is shown in the table below. The listing is not complete but highlights the most important directories.</p>
+<p>The source code layout for the deqp test modules and supporting libraries is
+shown in the table below (the listing is not comprehensive but highlights the
+most important directories).</p>
 
 <table>
  <tr>
@@ -93,6 +110,12 @@
 <td><p>GLES3.1 module</p>
 </td>
  </tr>
+  <tr>
+    <td><code>
+        modules/gles32</code></td>
+<td><p>GLES3.2 module</p>
+</td>
+ </tr>
  <tr>
     <td><code>targets</code></td>
 <td><p>Target-specific build configuration files</p>
@@ -153,6 +176,8 @@
  </tr>
 </table>
 
-<h3 id=open-source_components>Open Source components</h3>
+<h3 id=open-source_components>Open source components</h3>
 
-<p>The deqp uses <code>libpng</code> and <code>zlib</code>. They can be fetched from the web with the script <code>external/fetch_sources.py </code>or with git pulls from git repositories <code>platform/external/[libpng,zlib]</code>.</p>
+<p>The deqp uses <code>libpng</code> and <code>zlib</code>, which can be fetched
+using the script <code>external/fetch_sources.py </code>or via git from
+<code>platform/external/[libpng,zlib]</code>.</p>