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