doc/testspecs/GLES3/performance.shaders.operator.txt

   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.