1. 26 Feb, 2011 2 commits
  2. 25 Feb, 2011 2 commits
  3. 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
  4. 14 May, 2010 2 commits
  5. 15 Jan, 2010 1 commit
  6. 09 Jan, 2010 1 commit
  7. 16 Jul, 2009 1 commit
  8. 30 Apr, 2009 1 commit
  9. 23 Apr, 2009 1 commit
  10. 29 Jun, 2008 1 commit
  11. 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
  12. 21 Feb, 2008 1 commit
  13. 25 Mar, 2007 1 commit