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 Shader operator performance tests 20 21 Tests: 22 + dEQP-GLES3.performance.shaders.operator.* 23 24 Includes: 25 + Arithmetic operators in vertex and fragment shaders 26 - Scalar and vector types 27 + Computation-only built-in functions 28 29 Excludes: 30 + Texture lookup built-in functions 31 - Covered in performance.texture. 32 + Certain built-in functions; to be added in the future 33 - modf 34 - functions with uint/uvec* return or parameter types 35 - matrix functions that also deal with non-matrices (e.g. outerProduct) 36 37 Description: 38 39 Each test case draws multiple times with different workload sizes. A workload 40 size means the iteration count of a uniform loop in the shader. Time for each 41 frame is measured, and the slope of the workload size vs frame time data is 42 estimated. This slope tells us the estimated increase in frame time caused by 43 a workload increase of 1 loop iteration. 44 45 Generally, the shaders contain not just the operation we're interested in (e.g. 46 addition) but also some other things (e.g. loop overhead). To eliminate this 47 cost, we actually do the measurements described above paragraph with two 48 programs, which contain different amounts of computation in the loop. Then we 49 can compute the cost of just one operation by appropriately subtracting the 50 estimated slopes, and dividing by the operation count difference between the 51 two programs. 52 53 At this point, the result tells us the increase in frame time caused by the 54 addition of one operation. Dividing this by the amount of draw calls in a frame, 55 and further by the amount of vertices or fragments in a draw call, we get the 56 time cost of one operation. 57 58 In reality, there sometimes isn't just a trivial linear dependence between 59 workload size and frame time. Instead, there tends to be some amount of initial 60 "free" operations. That is, it may be that all workload sizes below some number 61 C yield the same frame time, and only workload sizes beyond C increase the frame 62 time in a supposedly linear manner. Graphically, this means that there graph 63 consists of two parts: a horizontal left part, and a linearly increasing right 64 part; the right part starts where the left parts ends. The principal task of 65 these tests is to look at the slope of the increasing right part. Additionally 66 an estimate for the amount of initial free operations is calculated. Note that 67 it is also normal to get graphs where the horizontal left part is of zero width, 68 i.e. there are no free operations. 69 70 Note that the tests use several fixed constants, such as the extent to which the 71 loops in the shaders are unrolled. These may not be the most suitable for all 72 platforms, and can be modified near the top of es2pShaderOperatorTests.cpp . 73 74 The unit of the test result is millions of operations per second. 75 76 See performance.txt for more details on shader performance testing. 77
