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). 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>
pgpg5MIw2lqF4.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
