OSDN Git Service

i965: Emit 3DSTATE_MULTISAMPLE before WM_HZ_OP (gen8+)
authorBen Widawsky <benjamin.widawsky@intel.com>
Thu, 21 May 2015 02:20:14 +0000 (19:20 -0700)
committerBen Widawsky <benjamin.widawsky@intel.com>
Thu, 28 May 2015 00:08:08 +0000 (17:08 -0700)
commite2d84d99f5a66738e8f584bdfea66182f36fe46c
treeb549ac134b7e9e65878426ffc813dc176f65da03
parent147ffd48166d851341cadd12de98895f32ec25a2
i965: Emit 3DSTATE_MULTISAMPLE before WM_HZ_OP (gen8+)

Starting with GEN8, there is documentation that the multisample state command
must be emitted before the 3DSTATE_WM_HZ_OP command any time the multisample
count changes. The 3DSTATE_WM_HZ_OP packet gets emitted as a result of a
intel_hix_exec(), which is called upon a fast clear and/or a resolve. This can
happen before the state atoms are checked, and so the multisample state must be
put directly in the function.

v1:
- In v0, I was always emitting the command, but Ken came up with the condition to
determine whether or not the sample count actually changed.
- Ken's recommendation was to set brw->num_multisamples after emitting
3DSTATE_MULTISAMPLE. This doesn't work. I put my best guess as to why in the XXX
(it was causing 7 regressions on BDW).

v2:
Flag NEW_MULTISAMPLE state. As Ken found, in state upload we check for the
multisample change to determine whether or not to emit certain packets. Since
the hiz code doesn't actually care about the number of multisamples, set the
flag and let the later code take care of it.

Jenkins results:
http://otc-mesa-ci.jf.intel.com/view/dev/job/bwidawsk/136/

Fixes around 200 piglit tests on SKL. I'm somewhat surprised that it seems to
have no impact on BDW as the restriction is needed there as well.

Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Neil Roberts <neil@linux.intel.com> (v0)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
src/mesa/drivers/dri/i965/gen8_depth_state.c