From 01ce1918dd1aa37f8a055bdc366e26f029893851 Mon Sep 17 00:00:00 2001 From: Robin Burchell Date: Thu, 4 May 2017 11:10:32 +0200 Subject: 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 --- README.md | 81 ---------------------- benchmarks/auto/animations/comparison/README.md | 17 +++++ benchmarks/auto/changes/README.md | 5 ++ benchmarks/auto/creation/README.md | 14 ++++ benchmarks/manual/gputhroughput/README.md | 16 +++++ benchmarks/manual/gputhroughput/blendedrect.qml | 2 + benchmarks/manual/gputhroughput/blendedtexture.qml | 2 + benchmarks/manual/gputhroughput/drawcalls.qml | 10 +++ benchmarks/manual/gputhroughput/gaussblur.qml | 4 ++ benchmarks/manual/gputhroughput/opaquerect.qml | 3 + benchmarks/manual/gputhroughput/opaquetexture.qml | 3 + 11 files changed, 76 insertions(+), 81 deletions(-) create mode 100644 benchmarks/auto/animations/comparison/README.md create mode 100644 benchmarks/auto/changes/README.md create mode 100644 benchmarks/auto/creation/README.md create mode 100644 benchmarks/manual/gputhroughput/README.md 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; -- cgit v1.2.3