On 09/22/2011 12:36 PM, Eric Anholt wrote: > No change in piglit results on gen6. > --- > src/mesa/drivers/dri/i965/gen6_cc.c | 20 ++++++++++++++++++++ > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/gen6_cc.c > b/src/mesa/drivers/dri/i965/gen6_cc.c > index b8047d5..1e6c4cf 100644 > --- a/src/mesa/drivers/dri/i965/gen6_cc.c > +++ b/src/mesa/drivers/dri/i965/gen6_cc.c > @@ -99,6 +99,26 @@ prepare_blend_state(struct brw_context *brw) > eqA != eqRGB); > } > > + /* See section 8.1.6 "Pre-Blend Color Clamping" of the > + * SandyBridge PRM Volume 2 Part 1 for HW requirements. > + * > + * We do our ARB_color_buffer_float CLAMP_FRAGMENT_COLOR > + * clamping in the fragment shader. For its clamping of > + * blending, the spec says: > + * > + * "RESOLVED: For fixed-point color buffers, the inputs and > + * the result of the blending equation are clamped. For > + * floating-point color buffers, no clamping occurs." > + * > + * So, generally, we want clamping to the render target's range. > + * And, good news, the hardware tables for both pre- and > + * post-blend color clamping are either ignored, or any are > + * allowed, or clamping is required but RT range clamping is a > + * valid option. > + */ > + blend[b].blend1.pre_blend_clamp_enable = 1; > + blend[b].blend1.post_blend_clamp_enable = 1; > + blend[b].blend1.clamp_range = BRW_RENDERTARGET_CLAMPRANGE_FORMAT; > > /* _NEW_COLOR */ > if (ctx->Color.AlphaEnabled) {
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev