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