1. 24 Nov, 2014 17 commits
  2. 21 Nov, 2014 7 commits
  3. 19 Nov, 2014 1 commit
    • Timothy Arceri's avatar
      arb_arrays_of_arrays: geometry shader tests · 572c76d2
      Timothy Arceri authored
      V2: Added Nvidia results to commit message
      Test results are from the following hardware/driver combination:
      AMD Radeon HD 6670 - Catalyst 13.251 OpenGL 4.3
      Nvidia Geforce GTX 570 - 340.24 OpenGL 4.4
      The Nvidia results do not always mean what they are intended
      to (e.g. passing for the wrong reason) as the driver doesn't
      allow multi dimensional arrays of interface blocks even
      though the spec says they are allowed. I've indicated these
      tests with a *
      AMD: pass
      Nvidia: fail*
      AMD: pass
      Nvidia: pass
      AMD: pass
      Nvidia: fail
      AMD: pass
      Nvidia: fail*
      AMD: pass
      Nvidia: pass
      AMD: fail
      Nvidia: pass*
      AMD: fail
      Nvidia: fail
      AMD: pass
      Nvidia: fail
      AMD: fail
      Nvidia: pass*
      AMD: pass
      Nvidia: fail*
      AMD: fail
      Nvidia: pass
      AMD: pass
      Nvidia: pass
      AMD: pass
      Nvidia: fail*
      AMD: fail
      Nvidia: pass*
      AMD: fail
      Nvidia: pass*
      Signed-off-by: Timothy Arceri's avatarTimothy Arceri <t_arceri@yahoo.com.au>
      Reviewed-by: Chris Forbes's avatarChris Forbes <chrisf@ijw.co.nz>
  4. 18 Nov, 2014 1 commit
    • Chris Forbes's avatar
      glsl-1.20: Add tests exposing some crashes with const arrays · 5e334960
      Chris Forbes authored
      I stumbled across these while implementing tessellation. In particular,
      the first test is a cutdown version of the tessellation nop.shader_test.
      The crash in array-initializers-1 is caused by the lowering of const arrays to
      uniforms. The hidden uniforms for both are named 'constarray', and a
      later phase in the linker gets horribly confused when it tries to look
      them up by name.
      I have not yet usefully characterized the crash in double-indirect-1,
      other than that it is in the i965 backend rather than in the GLSL
      Signed-off-by: Chris Forbes's avatarChris Forbes <chrisf@ijw.co.nz>
      Reviewed-by: Ilia Mirkin's avatarIlia Mirkin <imirkin@alum.mit.edu>
  5. 17 Nov, 2014 3 commits
    • Neil Roberts's avatar
      Add a test for GLX_ARB_context_flush_control · 0a3404cd
      Neil Roberts authored
      The test takes the following steps using two threads. The threads are
      only used so it can operate on another context without having to
      rebind it. The threads are run lock-step so that each step is run
      Thread 1: Make a flushless context A
      Thread 1: Make a flushy context B, shared with A
      Thread 1: Make a flushy context C, shared with A
      Thread 1: Bind context A
      Thread 2: Bind context C
      Thread 1: Make a renderbuffer.
      Thread 1: glClear() it to green.
      Thread 1: glFinish()
      Thread 1: glClear() it to red.
      Thread 2: Do a glReadPixels()
      (At this point the GL implementation is allowed to have finished
      the clear to red but it probably won't have. If the read pixels
      returns green here then it's not a failure but the test won't work
      so it will report PIGLIT_SKIP)
      Thread 1: Bind context C
      Thread 1: sleep(.5)
      Thread 2: Make sure glReadPixels() is still green, otherwise fail.
      All of the steps are then run again but this time context A is made
      flushy and the last step ensures that the pixel becomes red instead
      of green. If it did become red then the GL successfully made a
      flush when context A was released.
      The test also verifies that calling glGetIntegerv with
      GL_CONTEXT_RELEASE_BEHAVIOR returns the expected value when setting
      the attribute to none and flush and also when the attribute is left
      out entirely.
    • Neil Roberts's avatar
      Add a test using gl_VertexID with glPolygonMode(GL_POINT) · 4c3fbba1
      Neil Roberts authored
      This currently exposes a bug in the i965 driver.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84677
    • Ilia Mirkin's avatar
      glsl-1.10: check that mul source is used before dest is written · e0c0726d
      Ilia Mirkin authored
      r600 cayman (currently) has a bug on cayman because each component is
      multiplied separately when constants are used, but the destination gets
      modified before all of the source is read out. This test reproduces that
      scenario where it will read the first .x correctly, but for the y
      component, it will read the "new" x.
      Signed-off-by: Ilia Mirkin's avatarIlia Mirkin <imirkin@alum.mit.edu>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
  6. 16 Nov, 2014 2 commits
  7. 15 Nov, 2014 7 commits
  8. 14 Nov, 2014 2 commits