diff options
author | Ben Widawsky <[email protected]> | 2015-05-20 19:20:14 -0700 |
---|---|---|
committer | Ben Widawsky <[email protected]> | 2015-05-27 17:08:08 -0700 |
commit | e2d84d99f5a66738e8f584bdfea66182f36fe46c (patch) | |
tree | b549ac134b7e9e65878426ffc813dc176f65da03 /docs | |
parent | 147ffd48166d851341cadd12de98895f32ec25a2 (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