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