Juha-Pekka Heikkila <juhapekka.heikk...@gmail.com> writes: > I think these patches create functionality which Kenneth, Eric and Matt > talk about in this discussion: > http://lists.freedesktop.org/archives/mesa-dev/2014-February/054991.html > > I ran piglit quick set with these changes on Ironlake and Ivybridge and I did > not see any regression. If this seems ok I can take a look what's with MAD > also since I now added MAC
Pre-gen6, the accumulator is always updaded by the previous arithmetric instruction's result. So, in instruction scheduling, when you have a MAC or something else reading the accumulator, you need the instruction that generated the accumulator value to still (immediately) precede it in the resulting schedule. I think you'll want something along the lines of the last_conditional_mod code in brw_schedule_instructions.cpp, but I haven't thought it through too carefully (it might end up just being a matter of using add_barrier_deps() instead). I guess that this happens to work in your testing because the explicit acc register write in the MUL (which isn't strictly necessary -- using NULL would work just as well as far as the hardware goes) forces all previous instructions to be scheduled before it, then the MAC that comes afterwards shows up as having no unresolved dependencies and happens to get chosen first.
pgpC2ts2oNsW6.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
