1. 25 Feb, 2017 1 commit
  2. 08 Feb, 2017 2 commits
  3. 04 Jul, 2016 1 commit
  4. 02 Jul, 2016 1 commit
  5. 24 May, 2016 2 commits
  6. 04 May, 2016 1 commit
  7. 12 Nov, 2015 1 commit
  8. 10 Nov, 2015 1 commit
  9. 23 Feb, 2015 4 commits
  10. 08 Jul, 2014 1 commit
  11. 03 Jun, 2014 1 commit
  12. 02 Jun, 2014 1 commit
  13. 29 Jan, 2014 2 commits
  14. 27 Sep, 2013 1 commit
    • Brian Paul's avatar
      builtin_functions.py: tweak integer constants · 78832d86
      Brian Paul authored
      This fixes some misleading fs-op-div-* failures when the driver does
      integer arithmetic with floating point.  When we compute the reciprocal
      of some integers we wind up with inexact floating point results.  So
      expressions like X/X result in 0.9999 or such.
      This patch tweaks the generator code to use some "nicer" integers
      so that X/X comes out as expected.
      Note the GLSL 1.10 spec, section 4.1.3:
      "However, there is no requirement that integers in the language map to
      an integer type in hardware. It is not expected that underlying hardware
      has full support for a wide range of integer operations."
  15. 29 Jul, 2013 3 commits
  16. 15 Jan, 2013 1 commit
  17. 22 May, 2012 1 commit
  18. 01 May, 2012 1 commit
  19. 20 Mar, 2012 1 commit
  20. 08 Sep, 2011 1 commit
    • Paul Berry's avatar
      generated_tests: work around bug in Windows numpy implementation. · 363d7ce6
      Paul Berry authored
      The windows implementation of numpy seems to have multiple independent
      copies of the int32 and uint32 types, as illustrated by this
      interactive session:
      Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on
      Type "help", "copyright", "credits" or "license" for more information.
      >>> import numpy
      >>> x = numpy.int32(5)
      >>> y = numpy.abs(x)
      >>> print type(x)
      <type 'numpy.int32'>
      >>> print type(y)
      <type 'numpy.int32'>
      >>> print type(x) == type(y)
      >>> exit()
      On Linux, the last "print" yields True, which is clearly the correct
      This duplication of int32 and uint32 classes was preventing
      builtin_function.py's glsl_type_of() function from being able to
      reliably determine the type of its argument, causing an assertion
      failure while building piglit.
      This patch works around the problem by creating tuples INT32_TYPES and
      UINT32_TYPES which contain the duplicate types.  These tuples are used
      instead of referring directly to numpy.int32 and numpy.uint32.
      On platforms that do not have this bug, the tuples are "oneples" (one
      element each) so there is no change in behavior.
      I've verified that on Linux, this change does not affect the generated
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40697Tested-by: default avatarVinson Lee <vlee@vmware.com>
  21. 07 Sep, 2011 2 commits
  22. 18 Aug, 2011 5 commits
  23. 15 Aug, 2011 1 commit
    • Paul Berry's avatar
      Add operator tests to auto-generated built-in function tests. · 62f30256
      Paul Berry authored
      This patch adds tests for the following built-in GLSL operators:
      - op-add, op-sub, op-mult, op-div: binary arithemetic operators on
        floats, vecs, mats, ints, and ivecs.
      - op-uplus, op-neg: unary arithmetic operators on floats, vecs, mats,
        ints, and ivecs.
      - op-gt, op-lt, op-ge, op-le: comparison operators on ints and floats.
      - op-eq, op-ne: equality and inequality comparison on any GLSL 1.20 type.
      - op-and, op-or, op-xor: logical operations on bools.
      - op-not: unary logical not on bools.
      - op-selection: trinary selection operator (x?y:z), where the first
        argument is a bool and the second and third arguments are any GLSL
        1.20 type.
      Note that implicit type conversions are not tested.  So, for instance,
      int * ivec is tested, but float * ivec is not.  This was in an effort
      to avoid generating an outrageous number of tests.
      Note also that the "shortcut" behavior of logical and/or and trinary
      selection is not tested.
      These tests leverage the same test generation framework used to test
      built-in functions, so the tests exercise vertex shaders, fragment
      shaders, and constant folding.
      All in all 1332 tests are added, in the subtrees
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
  24. 11 Aug, 2011 1 commit
    • Paul Berry's avatar
      Increase the range of values used to test atan(x) and atan(x,y) · 978488e9
      Paul Berry authored
      This patch ensures that Piglit tests both atan(x) and atan(x,y) for
      both very small and very large inputs.
      Previously, Piglit only tested the atan() functions over a small range
      of input values, causing it to miss a bug in Mesa (which has since
      been fixed--see Mesa commit b1b4ea0b).
  25. 10 Aug, 2011 1 commit
    • Paul Berry's avatar
      Generated tests: unify code for testing exp2 across all numpy versions. · b0517d17
      Paul Berry authored
      Versions of numpy previous to 1.3.0 (such as the one that ships with
      Snow Leopard, which is 1.2.1) didn't include an exp2() function, so
      commit a5180ddc worked around the problem by emulating it using
      power(2, x) when the numpy version was less than 1.3.0.
      There is no real advantage to using exp2() over power(2, x) (other
      than to save a few keystrokes), but there is a maintenance advantage
      to being as consistent as possible across numpy versions.  So this
      patch changes Piglit to use power(2, x) regardless of the numpy
  26. 06 Aug, 2011 1 commit
  27. 05 Aug, 2011 1 commit
    • Paul Berry's avatar
      Add tolerance to auto-generated built-in function tests. · b4274e75
      Paul Berry authored
      Previously, the auto-generated tests converted their outputs to pixel
      values and tested them against the expected values using
      shader_runner's "probe rgba" command--as a result, the built-in
      functions only tested to a tolerance of 1 part in 255.
      This patch changes the auto-generated tests so that the expected value
      is checked inside the shader itself, to an explicit tolerance.
      Unfortunately, the GLSL and OpenGL specs are somewhat ambiguous as to
      how accurate the built-in functions need to be.  Section 2.1.1 of the
      OpenGL 2.1 spec, for instance, says that "individual results of
      floating point operations are accurate to about 1 part in 10^5".
      However, it's not clear whether a built-in function is intended to
      constitute a single "operation" in this context.  And in experimenting
      with the systems available to me (Mesa on Intel i965, both IronLake
      and SandyBridge, and an nVidia system running nVidia's proprietary
      Linux driver), I've found that trig functions in particular fail to
      meet this strict requirement.  Considering how trig functions are
      typically used in shaders (e.g. calculating lighting angles), it seems
      like 1 part in 10^5 is an unreasonably tight limit.
      So I've settled for the time being on the following compromise:
      - Trig functions are tested to a tolerance of 1 part in 10^3 relative
        to the output of the built-in function, or an absolute tolerance of
        10^-4, whichever is larger.
      - The cross product is tested to a tolerance of 1 part in 10^5,
        relative to the product of the magnitudes of the input vectors.
        This avoids an unreasonably tight tolerance in cases where the terms
        of the cross product cancel out, yielding a small result.
      - All other functions are tested to a tolerance of 1 part in 10^5
        relative to the output of the built-in function.
      To avoid additional sources of error due to floating-point
      conversions, all test vectors are generated as 32-bit floating-point
      As an aid in review, here is the generated test for the exp()
      GLSL >= 1.10
      [vertex shader]
      varying vec4 color;
      uniform float arg0;
      uniform float tolerance;
      uniform float expected;
      void main()
        gl_Position = gl_Vertex;
        float result = exp(arg0);
        color = distance(result, expected) <= tolerance ? vec4(0.0, 1.0, 0.0, 1.0) : vec4(1.0, 0.0, 0.0, 1.0);
      [fragment shader]
      varying vec4 color;
      void main()
        gl_FragColor = color;
      uniform float arg0 -2.0
      uniform float expected 0.13533528
      uniform float tolerance 1.3533528e-06
      draw rect -1 -1 2 2
      probe rgba 0 0 0.0 1.0 0.0 1.0
      uniform float arg0 -0.66666669
      uniform float expected 0.51341712
      uniform float tolerance 5.1341713e-06
      draw rect -1 -1 2 2
      probe rgba 1 0 0.0 1.0 0.0 1.0
      uniform float arg0 0.66666669
      uniform float expected 1.9477341
      uniform float tolerance 1.9477342e-05
      draw rect -1 -1 2 2
      probe rgba 2 0 0.0 1.0 0.0 1.0
      uniform float arg0 2.0
      uniform float expected 7.3890562
      uniform float tolerance 7.3890566e-05
      draw rect -1 -1 2 2
      probe rgba 3 0 0.0 1.0 0.0 1.0