1. 16 Mar, 2018 1 commit
  2. 05 Feb, 2018 5 commits
  3. 03 Jan, 2018 6 commits
  4. 26 Nov, 2017 1 commit
    • Roland Scheidegger's avatar
      fbo-blending-snorm: new test for testing snorm blend behavior · 1c80d7d2
      Roland Scheidegger authored
      The existing fbo-blending-formats test is mostly useless for anything but
      unorm formats, since it does not test any values outside [0,1] (neither for
      src, dst, intermeidate calculations, blend result).
      I tried to enhance it but it got too complex, in particular because I really
      want to test snorm, not floats (which aren't really validated much neither),
      because if you actually use int math for them it's difficult to handle and
      llvmpipe had lots of bugs. And it's not even obvious from the GL spec when
      clamping actually happens (in particular, the inverse blend factors will be
      in range [0,2]). snorm blending is sort of semi-supported in GL, the
      presence of EXT_texture_snorm doesn't guarantee it (and nvidia doesn't support
      the extension, presumably because they can't or don't want to deal with the
      legacy alpha/luminance/intensity formats), and while GL 3.1 introduces the
      snorm formats too it isn't guaranteed for rendering neither (for GLES OTOH
      there's a EXT_render_snorm extension), so the format handling of the
      fbo-blending-formats test isn't really sufficient and not easily extensible.
      So, this test will test actual blend behavior with values which will need
      clamping, and where the intermediate and final values will be negative (and,
      for the inverse blend factors, be even larger than one).
      This passes (now) on llvmpipe, and nvidia blob. softpipe is a complete
      failure (if there's clamping it will always clamp to [0,1] for starters),
      and as a matter of fact, softpipe doesn't get the clamping right even with
      unorm neither, since values outside [0,1] won't get clamped in the tile
      cache when there's no clamping, hence they'll enter the blend later when
      blend is enabled unclamped - but there's no test for this (note this is
      only an issue if the fragment color clamp is disabled).
      Reviewed-by: Jose Fonseca's avatarJose Fonseca <jfonseca@vmware.com>
      1c80d7d2
  5. 06 Nov, 2017 1 commit
  6. 03 Oct, 2017 1 commit
    • Nicolai Hähnle's avatar
      fbo-viewport: fix false error caused by slight rounding differences · ff037c1d
      Nicolai Hähnle authored
      This test compares rendering to the window system framebuffer with
      rendering to an FBO, and it does so by rendering rotated quads. There
      can be slight differences in rounding if the Y axis is flipped between
      those buffers causing rendering differences which are permitted by GL.
      
      Change the test to render axis-aligned quads in each viewport instead.
      This should still catch any error with flipped Ys, and there are no
      rounding issues since pixels are fully covered by quads.
      Reviewed-by: Brian Paul's avatarBrian Paul <brianp@vmware.com>
      ff037c1d
  7. 24 Jul, 2017 1 commit
  8. 28 Jun, 2017 1 commit
  9. 22 Jun, 2017 1 commit
  10. 07 Jun, 2017 1 commit
  11. 01 Jun, 2017 4 commits
  12. 18 May, 2017 1 commit
  13. 12 Dec, 2016 2 commits
  14. 14 Oct, 2016 3 commits
    • Ian Romanick's avatar
      fbo: Require ARB_texture_non_power_of_two in a test that doesn't strictly need it · b5007108
      Ian Romanick authored
      This test could be made to work without ARB_texture_non_power_of_two.
      However, it has a bunch of hardcoded pixel locations that would need to
      be updated for a new size.  I was lazy.  The only driver that I could
      find that supports the other requirements of this test (i.e.,
      ARB_fragment_program) and not ARB_texture_non_power_of_two is NV30.
      
      This /should/ make this test go from FAIL to SKIP on NV30, but I have
      not tested.  It should not affect any other driver.  Ilia says that the
      test already skips on NV30 with the output "FBO incomplete (status =
      0x8cd6)".
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Brian Paul's avatarBrian Paul <brianp@vmware.com>
      b5007108
    • Ian Romanick's avatar
      fbo: Require ARB_texture_non_power_of_two in some tests that implicitly require it · 69b71d81
      Ian Romanick authored
      Each of these tests requires either EXT_draw_buffers2, ARB_texture_rg,
      or >= 2 render targets.  I know of no hardware or driver that ever
      supported any of that functionality and not
      ARB_texture_non_power_of_two also.
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Brian Paul's avatarBrian Paul <brianp@vmware.com>
      69b71d81
    • Ian Romanick's avatar
      fbo: Ensure power-of-two window size in tests that make textures w/the window size · 858b4e67
      Ian Romanick authored
      Commit 0f163d1d removed the non-default window size from many tests.
      However, quite a few of these tests had power-of-two window sizes for
      drivers that do not support GL_ARB_texture_non_power_of_two.
      
      Fixes
      
          fbo-nodepth-test on NV20 and i865G
          fbo-nostencil-test on NV20 and i865G
          fbo-alphatest-formats on i865G
          fbo-blending-formats on NV20 and i865G
      
      Somehow fbo-alphatest-formats was previously passing on NV20.
      
      There are still a few failures in fbo-blending-formats on i865G, but the
      test mostly passes.  The remaining failures there are likely legitimate
      problems.
      
      None of the tests were fixed on R200, and both fbo-alphatest-formats and
      fbo-blending-formats go from FAIL to CRASH.  Both hit an assertion:
      
      main/format_utils.c:178: _mesa_compute_rgba2base2rgba_component_mapping: Assertion `!&"Unexpected base format"' failed.
      
      This should also fix these tests on NV10, NV30, and r100.  I suspect
      r100 will have the same troubles as r200.
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Brian Paul's avatarBrian Paul <brianp@vmware.com>
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      858b4e67
  15. 08 Aug, 2016 1 commit
  16. 01 Jul, 2016 1 commit
  17. 27 Jun, 2016 3 commits
  18. 08 Apr, 2016 1 commit
    • Oded Gabbay's avatar
      fbo-pbo-readpixels-small: make it endian-safe · 50ab640e
      Oded Gabbay authored
      In this test we use GL_BGRA + GL_UNSIGNED_BYTE. However, the probe
      function receives two 4-byte values to compare, expected and observed.
      This is wrong as the correct way to compare array_of_bytes
      (GL_UNSIGNED_BYTE) in an endian-safe way is by comparing memory (and not
      values).
      
      This patch fixes this bug by changing the function to receive two
      pointers instead of values. It also corrects the way the expected values
      are constructed to be in endian-safe way for array-of-bytes
      
      This fixes the test in llvmpipe, softpipe and r600g in big-endian machine.
      
      v2: Changed initialization of expected results to be more clear
      v3: Changed printing of results to display individual components
      v4: Changes some indentation
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      v2: Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      50ab640e
  19. 29 Feb, 2016 2 commits
  20. 03 Feb, 2016 1 commit
  21. 30 Nov, 2015 1 commit
  22. 12 Nov, 2015 1 commit