doc/testspecs/GLES31/functional.debug.txt

   1 -------------------------------------------------------------------------
   2 drawElements Quality Program Test Specification
   3 -----------------------------------------------
   4
   5 Copyright 2014 The Android Open Source Project
   6
   7 Licensed under the Apache License, Version 2.0 (the "License");
   8 you may not use this file except in compliance with the License.
   9 You may obtain a copy of the License at
  10
  11      http://www.apache.org/licenses/LICENSE-2.0
  12
  13 Unless required by applicable law or agreed to in writing, software
  14 distributed under the License is distributed on an "AS IS" BASIS,
  15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  16 See the License for the specific language governing permissions and
  17 limitations under the License.
  18 -------------------------------------------------------------------------
  19     GLES 3.1 debug (KHR_debug)
  20
  21 Tests:
  22  + dEQP-GLES31.functional.debug.*
  23
  24 Includes:
  25  + Reporting basic API errors
  26    - Callback
  27    - Log
  28    - glGetError
  29  + Application generated messages
  30    - InsertMessage
  31    - Push/Pop
  32  + Message filtering
  33  + Debug groups
  34  + Asynchronous output
  35    - Most cases use synchronous
  36  + Labels (for all valid object types)
  37  + Handling for debug/non-debug contexts
  38  + Limits (MAX_DEBUG_MESSAGE_LENGTH, MAX_DEBUG_LOGGED_MESSAGES)
  39
  40 Excludes:
  41  + Negative API tests for the extension itself
  42  + Some API errors
  43  + Labeled objects are not used for anything
  44  + Initial state of DEBUG_OUTPUT
  45
  46
  47 Description:
  48
  49 KHR_debug does not require generating messages if the GL context is not a
  50 debug context. The verification logic takes this into account and thus the
  51 tests have significantly lower criteria for passing when not running in a
  52 debug context. In situations that would not pass with a debug context (and
  53 some other suspect cases) a quality warning is generated instead.
  54 As such any real testing of this feature should be done in a debug context.
  55
  56 Tests can be run in a debug context with the --deqp-gl-context-flags=debug
  57 command line argument
  58
  59 Basic API error conditions are tested by calling the API in a manner that should
  60 generate errors and verifying that appropriate errors were generated.
  61 Verification is performed with a callback, querying the error log or GetError.
  62 Other than the fetching of errors (where necessary) the API usage is identical
  63 between equivalent test cases with different verification methods.
  64
  65 Application generated messages are generated with DebugMessageInsert and
  66 Push/Pop DebugGroup and verified with a callback.
  67
  68 Message filtering tests use a partially randomized set of API calls. The
  69 messages produced by these calls are first gathered without any filtering.
  70 Filtering is then enabled with a randomized set of changes from the base
  71 (unfiltered) state and the API calls are re-run. The messages from the second
  72 run are verified to be the correct subset of messages from the first run.
  73
  74 Debug groups are tested with an extended version of filtering tests.
  75 Filtering tests are essentially run several times with the same set of API
  76 calls and with verification after every push/pop.
  77
  78 Asynchronous message generation is tested by running the same set of API calls
  79 first with DEBUG_OUTPUT_SYNCHRONOUS enabled and then with it disabled and
  80 comparing the generated messages. The set of API calls used is randomized.
  81 Some async cases use callbacks while others query the debyg message log.
  82 Other than the calls necessari to query the log these cases use identical
  83 framework code.
  84
  85 Labels are set and immediately read back.