summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorBen Widawsky <[email protected]>2015-05-20 19:20:14 -0700
committerBen Widawsky <[email protected]>2015-05-27 17:08:08 -0700
commite2d84d99f5a66738e8f584bdfea66182f36fe46c (patch)
treeb549ac134b7e9e65878426ffc813dc176f65da03 /docs
parent147ffd48166d851341cadd12de98895f32ec25a2 (diff)
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" <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Neil Roberts <[email protected]> (v0) Reviewed-by: Kenneth Graunke <[email protected]> (v2)
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions