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