On Mon, Feb 03, 2014 at 11:30:58AM -0800, Eric Anholt wrote: > Topi Pohjolainen <topi.pohjolai...@intel.com> writes: > > > Previously the color components where evaluated using formula > > (src_color * src_color + 1.0 dst_color) and alpha in turn using > ^ 0.0 > > (1.0 * src_alpha + 0.0 * dst_alpha). The intention is to keep > > source color components unmodified and force alpha channel to > > fixed value of one regardless of source or destination. > > Not multiplying the source color by source color makes a lot of sense. > But your CONSTANT_ALPHA with ALPHA of 1.0 is the same as just using ONE. > (you're still multiplying the src alpha by 1.0 with your change, not > replacing the source alpha value with 1.0).
Oh, that is true, it is still just a multiplier. > > Basically, I think your original patch is equivalent to this and bettter > than this, and if we want to actually make the no-alpha-bits-present > thing work, we need to override the bits in the surface state or in the > generated code. In the normal draw path, it's done for sampling by the > swizzling code in brw_wm_surface_state.c, and the blending overrides is > just to fix up the alpha blending stage which doesn't pay attention to > that for the destination surface. > > So, the original patch is: > > Reviewed-by: Eric Anholt <e...@anholt.net> Ok, thanks for the careful review! _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
