1. 15 Jan, 2011 3 commits
  2. 14 Jan, 2011 6 commits
  3. 13 Jan, 2011 1 commit
  4. 12 Jan, 2011 5 commits
  5. 07 Jan, 2011 4 commits
  6. 04 Jan, 2011 3 commits
  7. 27 Dec, 2010 1 commit
  8. 16 Dec, 2010 1 commit
  9. 15 Dec, 2010 1 commit
  10. 30 Nov, 2010 3 commits
  11. 12 Nov, 2010 2 commits
  12. 30 Aug, 2010 3 commits
    • Vinson Lee's avatar
      arb_color_buffer_float: Define GL_COLOR_ATTACHMENT[01] if not defined. · 9a1fa8ba
      Vinson Lee authored
      Fixes build on Ubuntu 9.04.
      9a1fa8ba
    • Vinson Lee's avatar
      arb_color_buffer_float: Fix MSVC build. · 75e2208b
      Vinson Lee authored
      Remove inline keyword.
      Move declaration before code.
      75e2208b
    • 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