Move test descriptions into the tests (and test dirs) themselves

This scales a lot better, and is what we're doing with other tests.

Change-Id: I30772db9d72dbaf1ec65e3598c334c6c40573568
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>

11 files changed, 76 insertions, 81 deletions

diff --git a/README.md b/README.md
index 0f0a283..07a0521 100644
--- a/README.md
+++ b/README.md
@@ -120,84 +120,3 @@ You can also run a subset of them by providing that directory instead:
 
 Or even individual tests, by passing the filenames directly.
 
-### benchmarks/auto/creation/
-
-This is a suite of tests to find out how good we are with creation, rendering
-and destruction of objects. Some of the tests are also written in such a way
-that they can be compared between each other -- these are usually noted in the
-descriptive comment at the top of the test.
-
-Creation is an important factor: our items should be light, as creating a dialog
-or page of UI can often creating a few hundred different items (especially Text,
-Item, Rectangle, etc). In addition to this, there's code outside of our control
-on the application end: JS logic, model interaction, database or file I/O all
-comes in addition - so we need to leave plenty of performance left over for the
-end user.
-
-### benchmarks/manual/gputhroughput
-
-These benchmarks test your GPU for the most part. The QML part is mostly there
-to set things up and the benchmark will fill the graphics pipeline with enough
-stuff to make it suffer.
-
-**Note**! These tests are only designed to be used with the sustained-fps shell.
-
-The purpose of these benchmarks is to give an indication how how much one can
-expect to put on screen, and to decide how big the screen can actually be.
-Especially in the embedded space where a low end chip may have to drive an HD
-display, these tests can help to illustrate if the GPU is up to the task or not.
-
-* ``blendedrect.qml``: Stacks x number of alphablended rectangles on top of
-  each other. Rough test of fillrate.
-* ``blendedtexture.qml``: Stacks x number of alphablended textures on top of
-  each other. Rouch test of fill and texel rate.
-* ``opaquerect.qml``: Stacks x number of opaque rectangles on top of each other.
-  Will go a lot higher than blendedrect if the target hardware supprts
-  [early-z](https://en.wikipedia.org/?title=Z-buffering)
-* ``opaquetexture.qml``: Stacks x number of opaque textures on top of each other.
-  Will go a lot higher than blendedtexture if target hardware supports
-  [early-z](https://en.wikipedia.org/?title=Z-buffering)
-
-The numbers in these benchmarks mean how many times you can fill the screen. Run
-them in --fullscreen to get the right numbers. 1 means your in trouble. 2 means
-you can manage with a lot of work. 4 and above and you should be good shape, GPU-wise.
-
-* ``drawcalls.qml``: Take this one with a grain of salt. Graphics drivers have a
-  lot of overhead in how drawing is set up, and seeing an individual GL call take
-  up to a millisecond (yes, a millisecond) is not uncommon. This test is a highly
-  constructed case to try to get a rough ballpart of how many discrete draw calls
-  the GL stack is capable of.
-
-  This is mostly important if you end up with an application that fails to do
-  batching in the scene graph renderer, but as this situation will typically
-  have many other performance problems, this may not be a useful benchmark for
-  the most part.
-* ``gaussblur.qml``: This benchmark is added to test how feasible live blurring
-  is. Live blurring is an extreme fillrate test and is only something that
-  should be considered on gaming and industrial hardware. And then you still
-  probably want to cheat :p
-
-### benchmarks/auto/animations/comparison/
-
-These benchmarks compare a number of different ways of moving images around, and
-are help validate the casual gaming idea which should be very viable with QML.
-
-The benchmarks give an indication of how many animated items can run
-simultaneously in the UI. It should be in the thousands.
-
-One quirk if you run these is that on a threaded renderloop, the animation one
-runs faster than animators. This is because the work is broken into two major
-chunks. One is doing the animation while the other is doing the batching in the
-renderer and scheduling the rendering. If those happen on separate threads, we
-get better parallelization so 'animation' comes out better.
-
-However, if you try again with QSG_RENDER_LOOP=windows in the environment,
-you'll see that if it all happens on the same thread, then animators are a bit
-cheaper (because they are simpler).
-
-### benchmarks/auto/changes
-
-These benchmarks help measure the impact of various types of changes in a scene
-(for instance, changing one text item out of many, changing all text items at
-once).
-
diff --git a/benchmarks/auto/animations/comparison/README.md b/benchmarks/auto/animations/comparison/README.md
new file mode 100644
index 0000000..a5c441d
--- /dev/null
+++ b/benchmarks/auto/animations/comparison/README.md
@@ -0,0 +1,17 @@
+# comparison
+
+These benchmarks compare a number of different ways of moving images around, and
+are help validate the casual gaming idea which should be very viable with QML.
+
+The benchmarks give an indication of how many animated items can run
+simultaneously in the UI. It should be in the thousands.
+
+One quirk if you run these is that on a threaded renderloop, the animation one
+runs faster than animators. This is because the work is broken into two major
+chunks. One is doing the animation while the other is doing the batching in the
+renderer and scheduling the rendering. If those happen on separate threads, we
+get better parallelization so 'animation' comes out better.
+
+However, if you try again with QSG_RENDER_LOOP=windows in the environment,
+you'll see that if it all happens on the same thread, then animators are a bit
+cheaper (because they are simpler).
diff --git a/benchmarks/auto/changes/README.md b/benchmarks/auto/changes/README.md
new file mode 100644
index 0000000..9e5a905
--- /dev/null
+++ b/benchmarks/auto/changes/README.md
@@ -0,0 +1,5 @@
+# changes
+
+These benchmarks help measure the impact of various types of changes in a scene
+(for instance, changing one text item out of many, changing all text items at
+once).
diff --git a/benchmarks/auto/creation/README.md b/benchmarks/auto/creation/README.md
new file mode 100644
index 0000000..f0303d9
--- /dev/null
+++ b/benchmarks/auto/creation/README.md
@@ -0,0 +1,14 @@
+# creation
+
+This is a suite of tests to find out how good we are with creation, rendering
+and destruction of objects. Some of the tests are also written in such a way
+that they can be compared between each other -- these are usually noted in the
+descriptive comment at the top of the test.
+
+Creation is an important factor: our items should be light, as creating a dialog
+or page of UI can often creating a few hundred different items (especially Text,
+Item, Rectangle, etc). In addition to this, there's code outside of our control
+on the application end: JS logic, model interaction, database or file I/O all
+comes in addition - so we need to leave plenty of performance left over for the
+end user.
+
diff --git a/benchmarks/manual/gputhroughput/README.md b/benchmarks/manual/gputhroughput/README.md
new file mode 100644
index 0000000..28800bb
--- /dev/null
+++ b/benchmarks/manual/gputhroughput/README.md
@@ -0,0 +1,16 @@
+# gputhroughput
+
+These benchmarks test your GPU for the most part. The QML part is mostly there
+to set things up and the benchmark will fill the graphics pipeline with enough
+stuff to make it suffer.
+
+**Note**! These tests are only designed to be used with the sustained-fps shell.
+
+The purpose of these benchmarks is to give an indication how how much one can
+expect to put on screen, and to decide how big the screen can actually be.
+Especially in the embedded space where a low end chip may have to drive an HD
+display, these tests can help to illustrate if the GPU is up to the task or not.
+
+Run them in --fullscreen to get the right numbers. 1 means your in trouble. 2 means
+you can manage with a lot of work. 4 and above and you should be good shape, GPU-wise.
+
diff --git a/benchmarks/manual/gputhroughput/blendedrect.qml b/benchmarks/manual/gputhroughput/blendedrect.qml
index 6fa2e00..cd0d2c6 100644
--- a/benchmarks/manual/gputhroughput/blendedrect.qml
+++ b/benchmarks/manual/gputhroughput/blendedrect.qml
@@ -1,5 +1,7 @@
 import QtQuick 2.0
 
+// Stacks x number of alphablended rectangles on top of each other.
+// Rough test of fillrate.
 Item {
     id: root;
     property int count: 10
diff --git a/benchmarks/manual/gputhroughput/blendedtexture.qml b/benchmarks/manual/gputhroughput/blendedtexture.qml
index bac0265..51f067e 100644
--- a/benchmarks/manual/gputhroughput/blendedtexture.qml
+++ b/benchmarks/manual/gputhroughput/blendedtexture.qml
@@ -1,5 +1,7 @@
 import QtQuick 2.0
 
+// Stacks x number of alphablended textures on top of each other.
+// Rouch test of fill and texel rate.
 Item {
     id: root;
     property int count: 8;
diff --git a/benchmarks/manual/gputhroughput/drawcalls.qml b/benchmarks/manual/gputhroughput/drawcalls.qml
index 7d9a14b..bdd6289 100644
--- a/benchmarks/manual/gputhroughput/drawcalls.qml
+++ b/benchmarks/manual/gputhroughput/drawcalls.qml
@@ -1,5 +1,15 @@
 import QtQuick 2.0
 
+// Take this one with a grain of salt. Graphics drivers have a
+// lot of overhead in how drawing is set up, and seeing an individual GL call take
+// up to a millisecond (yes, a millisecond) is not uncommon. This test is a highly
+// constructed case to try to get a rough ballpart of how many discrete draw calls
+// the GL stack is capable of.
+//
+// This is mostly important if you end up with an application that fails to do
+// batching in the scene graph renderer, but as this situation will typically
+// have many other performance problems, this may not be a useful benchmark for
+// the most part.
 Item {
     id: root;
 
diff --git a/benchmarks/manual/gputhroughput/gaussblur.qml b/benchmarks/manual/gputhroughput/gaussblur.qml
index bb96147..8c8860e 100644
--- a/benchmarks/manual/gputhroughput/gaussblur.qml
+++ b/benchmarks/manual/gputhroughput/gaussblur.qml
@@ -1,6 +1,10 @@
 import QtQuick 2.2
 import QtGraphicalEffects 1.0
 
+// This benchmark is added to test how feasible live blurring
+// is. Live blurring is an extreme fillrate test and is only something that
+// should be considered on gaming and industrial hardware. And then you still
+// probably want to cheat :p
 Item {
     id: root;
     property int count: 8
diff --git a/benchmarks/manual/gputhroughput/opaquerect.qml b/benchmarks/manual/gputhroughput/opaquerect.qml
index 641e188..dd1a07b 100644
--- a/benchmarks/manual/gputhroughput/opaquerect.qml
+++ b/benchmarks/manual/gputhroughput/opaquerect.qml
@@ -1,5 +1,8 @@
 import QtQuick 2.0
 
+// Stacks x number of opaque rectangles on top of each other.
+// Will go a lot higher than blendedrect if the target hardware supprts
+// [early-z](https://en.wikipedia.org/?title=Z-buffering)
 Item {
     id: root;
     property int count: 16;
diff --git a/benchmarks/manual/gputhroughput/opaquetexture.qml b/benchmarks/manual/gputhroughput/opaquetexture.qml
index 483903a..07762e0 100644
--- a/benchmarks/manual/gputhroughput/opaquetexture.qml
+++ b/benchmarks/manual/gputhroughput/opaquetexture.qml
@@ -1,5 +1,8 @@
 import QtQuick 2.0
 
+// Stacks x number of opaque textures on top of each other.
+// Will go a lot higher than blendedtexture if target hardware supports
+// [early-z](https://en.wikipedia.org/?title=Z-buffering)
 Item {
     id: root;