fuchsia / third_party / vulkan-cts / refs/tags/opengl-cts-4.6.1.0 / . / doc / testspecs / GLES2 / performance.shaders.operator.txt

------------------------------------------------------------------------- | |

drawElements Quality Program Test Specification | |

----------------------------------------------- | |

Copyright 2014 The Android Open Source Project | |

Licensed under the Apache License, Version 2.0 (the "License"); | |

you may not use this file except in compliance with the License. | |

You may obtain a copy of the License at | |

http://www.apache.org/licenses/LICENSE-2.0 | |

Unless required by applicable law or agreed to in writing, software | |

distributed under the License is distributed on an "AS IS" BASIS, | |

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |

See the License for the specific language governing permissions and | |

limitations under the License. | |

------------------------------------------------------------------------- | |

Shader operator performance tests | |

Tests: | |

+ dEQP-GLES2.performance.shaders.operator.* | |

Includes: | |

+ Arithmetic operators in vertex and fragment shaders | |

- Scalar and vector types | |

+ Computation-only built-in functions | |

Excludes: | |

+ Texture lookup built-in functions | |

- Covered in performance.texture. | |

Description: | |

Each test case draws multiple times with different workload sizes. A workload | |

size means the iteration count of a uniform loop in the shader. Time for each | |

frame is measured, and the slope of the workload size vs frame time data is | |

estimated. This slope tells us the estimated increase in frame time caused by | |

a workload increase of 1 loop iteration. | |

Generally, the shaders contain not just the operation we're interested in (e.g. | |

addition) but also some other things (e.g. loop overhead). To eliminate this | |

cost, we actually do the measurements described above paragraph with two | |

programs, which contain different amounts of computation in the loop. Then we | |

can compute the cost of just one operation by appropriately subtracting the | |

estimated slopes, and dividing by the operation count difference between the | |

two programs. | |

At this point, the result tells us the increase in frame time caused by the | |

addition of one operation. Dividing this by the amount of draw calls in a frame, | |

and further by the amount of vertices or fragments in a draw call, we get the | |

time cost of one operation. | |

In reality, there sometimes isn't just a trivial linear dependence between | |

workload size and frame time. Instead, there tends to be some amount of initial | |

"free" operations. That is, it may be that all workload sizes below some number | |

C yield the same frame time, and only workload sizes beyond C increase the frame | |

time in a supposedly linear manner. Graphically, this means that there graph | |

consists of two parts: a horizontal left part, and a linearly increasing right | |

part; the right part starts where the left parts ends. The principal task of | |

these tests is to look at the slope of the increasing right part. Additionally | |

an estimate for the amount of initial free operations is calculated. Note that | |

it is also normal to get graphs where the horizontal left part is of zero width, | |

i.e. there are no free operations. | |

Note that the tests use several fixed constants, such as the extent to which the | |

loops in the shaders are unrolled. These may not be the most suitable for all | |

platforms, and can be modified near the top of es2pShaderOperatorTests.cpp . | |

The unit of the test result is millions of operations per second. | |

See performance.txt for more details on shader performance testing. |