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 Long-running stress tests 20 21 Tests: 22 + dEQP-GLES2.stress.long.* 23 24 Includes: 25 + Long-running stress testing with various application behaviors 26 + Memory object handling 27 - Buffers and textures 28 - Allocation, uploading 29 + Shader program 30 - Switching between several programs 31 - Re-compile frequently 32 + Draw calls 33 - Client-memory data for vertex indices and attributes 34 - Big draw calls 35 36 Excludes: 37 + Functional verification 38 39 Description: 40 41 The long-running stress tests are meant to be run for a long time to detect 42 deterioration (e.g. crash) in the program's behavior. The tests are supposed 43 to be run with the command-line tools instead of Candy. The test case uses 44 the --deqp-test-iteration-count=<num> command line option to choose the number 45 of iterations it runs; this should be set to either a very big number, or 46 alternatively a negative number, in which case it runs indefinitely. When 47 this option is not given, the number of iterations is only 5; this is only 48 useful to check that the test case's basic requisites are fulfilled (e.g. 49 that its shader programs compile successfully). 50 51 The basic structure of one iteration of the stress cases is as follows. 52 53 First, if the case uses more than one program, it randomly picks one of them 54 as the program for the current iteration. It then chooses whether or not to 55 re-compile the program if it hasn't yet been compiled. When a program is re- 56 compiled, attribute, uniform and varying names in the shader sources may 57 be mangled with a unique suffix, thus attempting to avoid shader caching. 58 59 Next, the textures used by the program are generated and uploaded or, if 60 they already exist, they may be re-uploaded with either glTexImage*() or 61 glTexSubImage*(). Texture parameters (wrapping etc.) are also set. 62 63 Then, buffers are generated and (re-)uploaded in a manner similar to that of 64 the textures described above. The buffers that may be used are vertex index 65 and attribute buffers. If, however, the case decides to use client-side memory 66 for index or attribute data, the respective buffer is not created. 67 68 Next, the program's uniforms are set, and a case-dependent amount of primitives 69 is drawn (note that this amount also affects the size of the buffers). This is 70 repeated for a case-dependent number of times. The draw command used can be 71 either glDrawElements() or glDrawArrays(). 72 73 After drawing, the case may delete some textures and/or buffers. 74 75 This concludes an iteration. Between iterations, the usual post-iteration 76 operations are done by the framework; this generally contains draw buffer 77 swapping. 78 79 A stress case's behavior is determined by its parameters: 80 + Program context(s) 81 - Vertex and fragment shader sources 82 - Value ranges for each attribute and uniform 83 - Texture information (size, format etc.) 84 + Approximate GPU memory usage limits that the case shouldn't exceed 85 - Texture memory 86 - Buffer memory 87 + Number of draw calls per iteration 88 + Number of triangles per draw call 89 + A set of probabilities that enable the following per-iteration actions: 90 - Re-build program 91 - Re-upload texture 92 - Re-upload buffer 93 - When re-uploading texture, use glTexImage*() instead of glTexSubImage*() 94 - When re-uploading buffer, use glBufferData() instead of glBufferSubData() 95 - Delete texture at end of iteration 96 - Delete buffer at end of iteration 97 - Don't re-use texture, but delay its deletion until memory limit is hit 98 - Don't re-use buffer, but delay its deletion until memory limit is hit 99 - Use random 'target' argument when uploading buffer 100 - Use random 'usage' argument when uploading buffer 101 - Use glDrawArrays() (and no index buffer) instead of glDrawElements() 102 - Use separate buffers for different attributes (instead of one big buffer) 103 (Note: the texture- or buffer-specific actions above are randomized both 104 per-iteration but also per-object.) 105
