Jason Ekstrand <ja...@jlekstrand.net> writes: > The only place when the fact that the MRFs are virtual matters is in > register allocation. Implied MRF writes are taken into account in > setup_mrf_hack_interference. We figure out what MRFs are used and > then mark them as conflicting with *all* of the VGRFs. We also force > them to be placed in the correct physical register using > ra_set_node_reg. The register allocator is then smart enough to not > place any other VGRF values into one of those registers. The problem > is that we were also forcing the message for the final FB write and we > were forcing it to overlap.
Ok, that makes sense. Thanks for the explanation. >> I was thinking it's a bit risky to just use a register that is lower >> than the lowest used MRF register because it could be possible for a >> message to use a really low register number and then this would end up >> using a negative register number. However in practice on Gen7+ it looks >> like there's hardly anything left that is using the fake MRF and we're >> unlikely to add more so it probably doesn't really matter. > > The maximum length of a message is 16 and we have at most 16 virtual > MRFs so the message will start no earlier than g96. I think it's fine > as long as it's in the upper half or something like that. Page 1039 of the Broadwell PRM says: “The send with EOT should use register space R112-R127 for <src>. This is to enable loading of a new thread into the same slot while the message with EOT for current thread is pending dispatch” So 96 wouldn't work. I guess that means if anything is using a base_mrf of 7 or below then it could potentially break. At a glance I can't find anything that would do that on Gen7+, but maybe it's a bit risky. Regards, - Neil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
