Matt Turner <matts...@gmail.com> writes: >> I'll have another look at moving it into brw_send_indirect_message. > > Thanks. I'm not really sure what the right solution is, so if you > decide this patch is good as is, that's fine with me.
Here's what the patches would look like if we made brw_send_indirect_message look more like brw_SAMPLE. The function needs to be changed to take a parameter for the base_mrf so that it can detect when send from MRF is being used so we also need to change the other places that call it. The functions that were generating the sample message based on a pseudo-opcode are now passing in their inst->base_mrf. However I also had to fix some places that weren't setting base_mrf so it was being left at 0, whereas it needs to be -1 to disable it. I think I would prefer to just go with the original patch because it seems a bit silly to have brw_send_indirect_message take a base_mrf parameter when the function is only relevant for Gen7+ which doesn't even have an MRF. I think the problem is only relevant in this particular case when brw_send_indirect_message is used for sampling because it's the only case that is still using the MRF hack. In that case it doesn't seem so bad to just resolve the MRF right there. - Neil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev