1
0
Fork 0
mutter-performance-source/tests
Robert Bragg 04d943579b gl: bind position attribute to location 0
Full GL treats the position attribute specially and requires that it
must be bound to generic attribute location 0 unlike GLES 2.0 or
GL 3.2 core. We now make sure to unconditionally bind the
cogl_position_in attribute to location 0 before linking any glsl program
in cogl.

For reference the relevant part of the GL 3.0 spec that covers these
semantics is Section 2.7 "Vertex Specification" pg 27

After this change there was one remaining problem in
test-custom-attributes where the test_short_verts() test was using its
own "pos" attribute instead of cogl_position_in and so cogl wasn't able
to ensure it would be bound to location 0.

This updates the test to use cogl_position_in but to work around the
fact that glVertexPointer doesn't support UNSIGNED_SHORT components we
force the test to use the glsl backend by setting a shader snippet on
the pipeline.

https://bugs.freedesktop.org/show_bug.cgi?id=67548

Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit 992ef7b3b49ebb56adde2133bb36330c04133a3f)
2013-08-19 22:44:45 +01:00
..
conform gl: bind position attribute to location 0 2013-08-19 22:44:45 +01:00
data Starts porting Cogl conformance tests from Clutter 2011-09-08 15:48:07 +01:00
micro-perf Add $(LIBM) to the LDADD for all of the examples and tests 2013-04-23 18:32:47 +01:00
unit Don't include cogl/cogl.h from test-utils.h 2013-07-04 11:50:31 +01:00
config.env.in tests: Adds our first white-box unit test 2013-06-06 21:27:16 +01:00
Makefile.am Install conformance tests 2013-07-09 22:52:50 +01:00
README Starts porting Cogl conformance tests from Clutter 2011-09-08 15:48:07 +01:00
run-tests.sh Set G_DEBUG=fatal-warnings in run-tests.sh 2013-06-21 14:18:40 +01:00
test-launcher.sh tests: Adds our first white-box unit test 2013-06-06 21:27:16 +01:00

Outline of test categories:

The conform/ tests:
-------------------
These tests should be non-interactive unit-tests that verify a single
feature is behaving as documented. See conform/ADDING_NEW_TESTS for more
details.

Although it may seem a bit awkward; all the tests are built into a
single binary because it makes building the tests *much* faster by avoiding
lots of linking.

Each test has a wrapper script generated though so running the individual tests
should be convenient enough. Running the wrapper script will also print out for
convenience how you could run the test under gdb or valgrind like this for
example:

  NOTE: For debugging purposes, you can run this single test as follows:
  $ libtool --mode=execute \
            gdb --eval-command="b test_cogl_depth_test" \
            --args ./test-conformance -p /conform/cogl/test_cogl_depth_test
  or:
  $ env G_SLICE=always-malloc \
    libtool --mode=execute \
            valgrind ./test-conformance -p /conform/cogl/test_cogl_depth_test

By default the conformance tests are run offscreen. This makes the tests run
much faster and they also don't interfere with other work you may want to do by
constantly stealing focus. CoglOnscreen framebuffers obviously don't get tested
this way so it's important that the tests also get run onscreen every once in a
while, especially if changes are being made to CoglFramebuffer related code.
Onscreen testing can be enabled by setting COGL_TEST_ONSCREEN=1 in your
environment.

The micro-bench/ tests:
-----------------------
These should be focused performance tests, ideally testing a
single metric. Please never forget that these tests are synthetic and if you
are using them then you understand what metric is being tested. They probably
don't reflect any real world application loads and the intention is that you
use these tests once you have already determined the crux of your problem and
need focused feedback that your changes are indeed improving matters. There is
no exit status requirements for these tests, but they should give clear
feedback as to their performance. If the framerate is the feedback metric, then
the test should forcibly enable FPS debugging.

The data/ directory:
--------------------
This contains optional data (like images) that can be referenced by a test.


Misc notes:
-----------
• All tests should ideally include a detailed description in the source
explaining exactly what the test is for, how the test was designed to work,
and possibly a rationale for the approach taken for testing.

• When running tests under Valgrind, you should follow the instructions
available here:

        http://live.gnome.org/Valgrind

and also use the suppression file available inside the data/ directory.