1. 23 Dec, 2017 1 commit
  2. 16 Dec, 2017 1 commit
  3. 12 Jul, 2017 1 commit
  4. 05 May, 2017 1 commit
    • Marek Olšák's avatar
      drawoverhead: new microbenchmark · c12816f7
      Marek Olšák authored
      Based on a benchmark from mesa/demos, but rewritten and extended.
      It's a benchmark expected to be run separately, not a piglit test.
      So why piglit? Because it's a good framework for writing apps like this.
      
      mesa_glthread won't show an improvement here, because there is no app
      overhead.
      
      This is what the output looks like. The percentage is relative to
      the first test of the given draw call.
      
      The obvious thing there is that enabled vertex attribs decrease
      Mesa performance even if there are no state changes.
      
      Using Core profile.
      Draw calls per second:
         DrawElements ( 1 VBOs, 0 UBOs,  0 Tex) w/ no state change:          5.71 million (100.0%)
         DrawElements ( 4 VBOs, 0 UBOs,  0 Tex) w/ no state change:          5.18 million (90.8%)
         DrawElements (16 VBOs, 0 UBOs,  0 Tex) w/ no state change:          3.65 million (63.9%)
         DrawElements ( 1 VBOs, 0 UBOs, 16 Tex) w/ no state change:          5.71 million (100.0%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ no state change:          5.78 million (101.2%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ shader program change:    220.11 thousand (3.9%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ vertex attrib change:     1.06 million (18.5%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ 1 texture change:         483.27 thousand (8.5%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ 8 textures change:        291.20 thousand (5.1%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ 1 UBO change:             1.84 million (32.3%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ 4 UBOs change:            1.12 million (19.7%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ few uniforms / 1 change:  2.27 million (39.8%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ many uniforms / 1 change: 966.00 thousand (16.9%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ blend enable change:      1.37 million (24.0%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ depth enable change:      1.86 million (32.6%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    1.66 million (29.0%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ scissor enable change:    1.09 million (19.1%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ MSAA enable change:       1.94 million (34.0%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ cull face enable change:  1.56 million (27.3%)
         DrawElements ( 1 VBOs, 4 UBOs,  8 Tex) w/ FB sRGB enable change:    200.81 thousand (3.5%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ shader program change:    186.92 thousand (3.3%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ vertex attrib change:     638.49 thousand (11.2%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ 1 texture change:         452.39 thousand (7.9%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ 8 textures change:        278.79 thousand (4.9%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ 1 UBO change:             1.47 million (25.7%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ 4 UBOs change:            974.30 thousand (17.1%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ few uniforms / 1 change:  1.79 million (31.3%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ many uniforms / 1 change: 853.07 thousand (14.9%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ blend enable change:      1.16 million (20.3%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ depth enable change:      1.49 million (26.2%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    1.35 million (23.7%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ scissor enable change:    946.45 thousand (16.6%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ MSAA enable change:       1.62 million (28.3%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ cull face enable change:  1.29 million (22.5%)
         DrawElements (16 VBOs, 4 UBOs,  8 Tex) w/ FB sRGB enable change:    126.44 thousand (2.2%)
         DrawArrays ( 1 VBOs, 0 UBOs,  0 Tex) w/ no state change:          8.02 million (100.0%)
         DrawArrays ( 4 VBOs, 0 UBOs,  0 Tex) w/ no state change:          7.14 million (89.0%)
         DrawArrays (16 VBOs, 0 UBOs,  0 Tex) w/ no state change:          4.26 million (53.0%)
         DrawArrays ( 1 VBOs, 0 UBOs, 16 Tex) w/ no state change:          7.89 million (98.4%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ no state change:          8.01 million (99.9%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ shader program change:    221.09 thousand (2.8%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ vertex attrib change:     1.13 million (14.1%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ 1 texture change:         500.25 thousand (6.2%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ 8 textures change:        294.30 thousand (3.7%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ 1 UBO change:             2.02 million (25.2%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ 4 UBOs change:            1.18 million (14.7%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ few uniforms / 1 change:  2.28 million (28.4%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ many uniforms / 1 change: 617.79 thousand (7.7%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ blend enable change:      1.59 million (19.8%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ depth enable change:      2.09 million (26.0%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    2.02 million (25.2%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ scissor enable change:    1.18 million (14.7%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ MSAA enable change:       2.27 million (28.3%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ cull face enable change:  1.77 million (22.1%)
         DrawArrays ( 1 VBOs, 4 UBOs,  8 Tex) w/ FB sRGB enable change:    204.60 thousand (2.6%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ shader program change:    191.50 thousand (2.4%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ vertex attrib change:     679.98 thousand (8.5%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ 1 texture change:         472.00 thousand (5.9%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ 8 textures change:        286.70 thousand (3.6%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ 1 UBO change:             1.69 million (21.0%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ 4 UBOs change:            1.04 million (13.0%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ few uniforms / 1 change:  2.04 million (25.5%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ many uniforms / 1 change: 620.41 thousand (7.7%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ blend enable change:      1.30 million (16.2%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ depth enable change:      1.69 million (21.0%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ stencil enable change:    1.55 million (19.3%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ scissor enable change:    1.04 million (13.0%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ MSAA enable change:       1.82 million (22.7%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ cull face enable change:  1.47 million (18.3%)
         DrawArrays (16 VBOs, 4 UBOs,  8 Tex) w/ FB sRGB enable change:    129.25 thousand (1.6%)
      c12816f7
  5. 31 Oct, 2013 1 commit
  6. 07 Jun, 2013 1 commit
  7. 03 Jun, 2013 1 commit
  8. 31 Dec, 2012 1 commit
  9. 30 Nov, 2012 1 commit
    • Chad Versace's avatar
      gles2: Remove directory tests/gles2 · a109c7d0
      Chad Versace authored
      This directory contained a single test, gles2_shader_runner, that was
      never used. It was a failed artifact from the time when we were scrambling
      to discover how to support GLES2 in piglit. Instead, GLES functionality
      has been added to the real shader runner, tests/shaders/shader_runner.c.
      
      In the future, any tests specific to GLES2 should go into the directory
      tests/spec/gles-2.0, just as we do for all other GL versions.
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      a109c7d0
  10. 10 Oct, 2012 2 commits
  11. 05 Sep, 2012 1 commit
  12. 28 Jun, 2012 1 commit
    • Brian Paul's avatar
      security/initialized-texmemory - test contents of unitialized texture memory · 4a14d11d
      Brian Paul authored
      This is the first of a new category of piglit tests that exercise
      things related to security.
      
      The first test, initialized-texmemory, creates a texture image with
      unspecified contents (pixels=NULL).  We draw a polygon with the texture
      and see what we get.  Ideally, we'd get a constant/black image and not
      some random VRAM data from another application or another user (like a
      window image).  The OpenGL spec doesn't say that texture memory should
      be initialized in this situation so if the test fails we return "WARN"
      rather than "FAIL".
      Reviewed-by: Jose Fonseca's avatarJosé Fonseca <jfonseca@vmware.com>
      4a14d11d
  13. 03 Mar, 2012 1 commit
    • Dylan Noblesmith's avatar
      don't write generated header to the source directory · 2cb512bd
      Dylan Noblesmith authored
      It was impossible to have the source directory read-only.
      
      Also add the include_directories() directive for tests/util
      in just one place, under tests/, so that all subdirectories
      inherit it. A bunch of CMakeLists.txt files duplicate it,
      so delete those redundant include flags:
      
      sed -i -e "/^\t\${piglit_SOURCE_DIR}\/tests\/util/ d" \
       `grep piglit_SOURCE_DIR -rl tests/ | grep "CMakeLists\.gl"`
      2cb512bd
  14. 26 Oct, 2011 1 commit
    • Chia-I Wu's avatar
      oes_draw_texture: Basic functionality tests for this extension · d7ad6130
      Chia-I Wu authored
      This is the first GLESv1 tests.  GL_OES_draw_texture is a GLESv1
      specific extension.
      
      The tests are added to the newly created all_es1.tests.
      
      Changes since v1:
      
       - rename the file name to oes_draw_texture.c
       - rename the static variable glDrawTexiOES to piglit_glDrawTexiOES
       - add all_es1.tests for this (and future) GLESv1 tests
      
      Changes since v2:
      
       - Put the test in tests/spec/oes_draw_texture instead of tests/gles1.
       - Minor fixes to all_es1.tests
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      d7ad6130
  15. 09 Sep, 2011 1 commit
  16. 13 May, 2011 1 commit
  17. 28 Apr, 2011 1 commit
  18. 26 Feb, 2011 3 commits
  19. 25 Feb, 2011 2 commits
  20. 30 Aug, 2010 1 commit
    • Luca Barbieri's avatar
      New testsuite for ARB_color_buffer_float (v2) · 15141eeb
      Luca Barbieri authored
      This in an updated version of the test I posted, now split into 8 tests
      sharing a common header file.
      
      It now features testing of multiple render targets and fog.
      
      Test output logs and results on GeForce 8xxx, GTX 2xx or ideally GTX 4xx
      with the proprietary drivers would be really welcome.
      
      The files are put in "spec/arb_color_buffer_float" with the idea of
      starting a convention of writing testsuites for each new extension
      to be implemented in Mesa, putting it in "spec/<extension_name>".
      
      The tests now fail on any bugs in the default mode.
      If "-xfail" is passed, then known bugs on ATI and nVidia will be ignored,
      and all tests will then succeed.
      
      The driver bugs don't seem due (solely) to hardware limitations, but may
      be due to software fallbacks being improperly implemented.
      
      There are two areas where the specification seems unclear, as far as I
      understand it.
      
      I'm not sure what the process to ask for clarification is, and suggestions
      would be welcome here.
      
      This first issue is whether, when fragment clamping is set to FIXED_ONLY
      and the FBO has some fixed-point and some floating-point buffers attached,
      gl_FragData[n] is never clamped, or is clamped only for the fixed point
      buffers.
      
      Note that while blending on fixed-point clamps the color anyway, alpha
      test and polygon smoothing happen before blending, and should be affected
      by whether gl_FragData[n] is clamped or not.
      
      From the OpenGL 4.1 spec, it seems that the intent is that fragment
      clamping does not depend on the target, especially because it can be
      bound dynamically due to user-defined varyings.
      
      None of the hardware I have access to supports such dishomogeneous FBOs,
      so I have no idea what the proprietary drivers do.
      
      Current nVidia cards might shed light on this.
      
      The second issue is whether disabling fragment clamping disables the
      clamping done before fog application in fragment shaders with ARB_fog_*
      options (or whether this is undefined)
      
      This happens in the fixed pipeline, but making it happen for shaders too
      would contradict the rationale of adding ARB_fog_* to shaders, which
      is to avoid recompilation.
      
      All the hardware I have access to has fixed function fog (all existing
      Radeons seem to have it), and here the disabling applies to fragment
      programs too, as a "naive" implementation would result in.
      
      Again, current nVidia cards might shed light on this.
      15141eeb
  21. 14 May, 2010 2 commits
  22. 15 Jan, 2010 1 commit
  23. 09 Jan, 2010 1 commit
  24. 16 Jul, 2009 1 commit
  25. 30 Apr, 2009 1 commit
  26. 23 Apr, 2009 1 commit
  27. 29 Jun, 2008 1 commit
  28. 19 Mar, 2008 1 commit
    • Eric Anholt's avatar
      Add a test for ARB_texture_cube_map · fae77c78
      Eric Anholt authored
      This test has seen only limited testing.  The GM945 driver fails in the
      expected way from code inspection.  More concerning is that Mesa software
      appears to select a mipmap one level smaller than it should.
      fae77c78
  29. 21 Feb, 2008 1 commit
  30. 25 Mar, 2007 1 commit