1. 30 Apr, 2014 2 commits
    • Brian Paul's avatar
      fbo: use default window size for fbo tests · 0f163d1d
      Brian Paul authored
      No regressions with NVIDIA's driver or llvmpipe.
      Reviewed-by: Jose Fonseca's avatarJosé Fonseca <jfonseca@vmware.com>
      0f163d1d
    • Peter Wu's avatar
      cl: Add complex real world test: Pyrit · 79bc2891
      Peter Wu authored
      Pyrit computes pairwise master keys (PMKs) to attack WPA/WPA2-PSK. This
      test verifies two aspects:
      
       - Computation of the second round of a HMAC (using SHA-1).
       - A calculation of the PMK key.
      
      Both tests use test vectors from IEEE 802.11-2012, pre-processed to fit
      in the model used by Pyrit (one part is pre-calculated before passing it
      to the kernel).
      
      The results have been verified with POCL and r600g (mesa master+llvm
      trunk).
      
      Signed-off-by: Peter Wu <lekensteyn at gmail.com>
      79bc2891
  2. 29 Apr, 2014 2 commits
  3. 28 Apr, 2014 1 commit
  4. 27 Apr, 2014 2 commits
  5. 26 Apr, 2014 9 commits
    • Brian Paul's avatar
      remove glean texSwizzle test · 4980d989
      Brian Paul authored
      Replaced by spec/ext_texture_swizzle/api.c and swizzle.c tests.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      4980d989
    • Brian Paul's avatar
      remove old tex-swizzle test · 6fb78b06
      Brian Paul authored
      It didn't test the GL_ONE and GL_ZERO terms and was needlessly
      complicated.  Replaced by ext_texture_swizzle-swizzle test.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      6fb78b06
    • Brian Paul's avatar
      add new texture swizzle API test · 4b4a5bec
      Brian Paul authored
      Test for API errors and glGet for GL_EXT_texture_swizzle.
      
      v2: minor re-org, per Eric
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      4b4a5bec
    • Brian Paul's avatar
      implement new texture swizzle test · e8aab11f
      Brian Paul authored
      The original one didn't test the GL_ONE and GL_ZERO terms and was
      pretty compilicated.  This tests all swizzle combinations and is
      much simpler.
      
      v2: remove stray '&& pass' per Eric.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      e8aab11f
    • Brian Paul's avatar
    • Brian Paul's avatar
      swapbuffers-behavior: check if swapbuffers swaps or copies · 1e5b46c0
      Brian Paul authored
      Probe front/back buffers after a SwapBuffers() call to see if the
      implementation does a true swap or a back-to-front copy.
      
      There is no pass/fail (except for one sanity check).  This is just
      to find out what GL does.
      1e5b46c0
    • Brian Paul's avatar
      normal3b3s-invariance: test GLbyte[3] and GLshort[3] normal vec invariance · b1ed5be4
      Brian Paul authored
      Test rendering invariance with GLfloat[3] vs. GLbyte[3] vs. GLshort[3]
      normal vectors.  See comments in code for more details.
      b1ed5be4
    • Ian Romanick's avatar
      sso: Verify results of program pipeline validation when a conflicting sampler... · 5702e433
      Ian Romanick authored
      sso: Verify results of program pipeline validation when a conflicting sampler configuration is used.
      
      Section 2.11.11 (Shader Execution), subheading "Validation," of the
      OpenGL 4.1 spec says:
      
          "[INVALID_OPERATION] is generated by any command that transfers
          vertices to the GL if:
      
              ...
      
              - Any two active samplers in the current program object are of
                different types, but refer to the same texture image unit."
      
      This test verifies this behavior several ways.  First, an invalid
      configuration is constructed.  When the pipeline is in the invalid
      configuration, glValidateProgramPipeline is used to determine the
      status.
      
      The pipeline is then transitioned to a valid configuration, and
      glValidateProgramPipeline is called again.
      
      The pipeline is then transitioned back to the invalid configuration.
      Without calling glValidateProgramPipeline, glDrawArrays is called.  This
      should generate the aforementioned error.  While still in the invalid
      state glValidateProgramPipeline is called a third time.
      
      Finally, the pipeline is transitioned back to the valid configuration.
      Without calling glValidateProgramPipeline, glDrawArrays is called.  This
      should not generate any error.
      
      All of the state flip-flopping is done in an attempt to catch
      implementations that latch state in glValidateProgramPipeline and do not
      re-validate in glDrawArrays.
      
      NOTE: The work-in-progress GL_ARB_separate_shader_objects implementation
      for Mesa currently fails this test because glValidateProgramPipeline
      always succeeds, and it does not generate GL_INVALID_OPERATION the first
      time glDrawArrays is called.
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Anuj Phogat's avatarAnuj Phogat <anuj.phogat@gmail.com>
      5702e433
    • Ian Romanick's avatar
      gl-2.0: Verify results of program validation when a conflicting sampler configuration is used. · 8b2caa1a
      Ian Romanick authored
      Section 2.15.4 (Shader Execution), subheading "Validation" of the OpenGL
      2.0 spec says:
      
          "[INVALID_OPERATION] is generated by Begin, RasterPos, or any
          command that performs an implicit Begin if:
      
              - any two active samplers in the current program object are of
                different types, but refer to the same texture image unit,"
      
      This test verifies this behavior several ways.  First, an invalid
      configuration is constructed.  When the program is in the invalid
      configuration, glValidateProgram is used to determine the status.
      
      The program is then transitioned to a valid configuration, and
      glValidateProgram is called again.
      
      The program is then transitioned back to the invalid configuration.
      Without calling glValidateProgram, glBegin is called.  This should
      generate the aforementioned error.  While still in the invalid state
      glValidateProgram is called a third time.
      
      Finally, the program is transitioned back to the valid configuration.
      Without calling glValidateProgram, glBegin is called.  This should not
      generate any error.
      
      All of the state flip-flopping is done in an attempt to catch
      implementations that latch state in glValidateProgram and do not
      re-validate in glBegin.
      
      NOTE: Mesa fails this test because it does not generate
      GL_INVALID_OPERATION the first time glBegin is called.
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Anuj Phogat's avatarAnuj Phogat <anuj.phogat@gmail.com>
      8b2caa1a
  6. 24 Apr, 2014 4 commits
  7. 23 Apr, 2014 2 commits
  8. 21 Apr, 2014 2 commits
  9. 19 Apr, 2014 1 commit
  10. 17 Apr, 2014 15 commits