i965/gen9: Annotate input coverage mask change
authorBen Widawsky <benjamin.widawsky@intel.com>
Wed, 26 Aug 2015 23:35:40 +0000 (16:35 -0700)
committerBen Widawsky <benjamin.widawsky@intel.com>
Thu, 3 Sep 2015 18:55:31 +0000 (11:55 -0700)
commitb05619c627122a0e35a18f92e457d3aefa55f2f7
tree9048fc30bd889917b82e65c2ab637f0e0fca93e3
parent70dbdca15fa173302481111cdfb86881dd13dc38
i965/gen9: Annotate input coverage mask change

As far as I can tell, the behavior is preserved from the previous generations.
Before we set a single bit to tell the FS whether or not we'll be using an input
coverage mask. Now we have some options which are implementing various
extensions. These bits are used for the various conservative rasterization
mechanisms (for collision detection, binning, and whatever else).

I believe that the behavior is preserved because the problem which conservative
rasterization is attempting to fix would go away with the "NORMAL" mode (at the
cost of performance, I believe).

This patch serves as documentation of the change by creating the enums, as well
as giving some of the history with the links here so that the next person who
comes along and looks at it doesn't spend as long as I had to in order to
determine if there is an issue or not.

Previously, this algorithm had been done in software, and this can still be used
as long as we don't export an extension stating otherwise.

References: https://www.opengl.org/registry/specs/NV/conservative_raster.txt
References: https://http.developer.nvidia.com/GPUGems2/gpugems2_chapter42.html
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/mesa/drivers/dri/i965/brw_defines.h
src/mesa/drivers/dri/i965/gen8_ps_state.c