On Fri, Oct 6, 2017 at 1:24 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 06.10.2017 um 00:34 schrieb Marek Olšák: >> On Thu, Oct 5, 2017 at 8:00 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Thu, Oct 5, 2017 at 1:45 PM, Marek Olšák <mar...@gmail.com> wrote: >>>> On Thu, Oct 5, 2017 at 4:45 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>>> Like Roland, I don't see what's being gained. It's more code >>>>> everywhere and harder to read the TGSI directly. >>>> >>>> Harder to read the "IMM" string in the operand? >>> >>> Yeah. You see a KILL_IF IMM[]... and then have to look up what that >>> immediate is among the 75 other immediates. For all you know it's not >>> -1 but something else. For long programs, this isn't great, esp if >>> you're matching things up to the GLSL. >>> >>>> >>>> "more code everywhere"? >>>> 21 files changed, 22 insertions(+), 200 deletions(-) >>>> >>>> This is the reason: 200 deletions(-) >>>> >>>>> >>>>> Neither nv30 nor nv50+ do the checks you suggest. >>>> >>>> But they can if they want. >>> >>> ... thus leading to more code. >>> >>> Anyways, since my (recent) ability to contribute has greatly >>> atrophied, I'm not going to explicitly NAK this. But you have my 2c. >> >> I don't really understand the backlash, and especially from nouveau it >> doesn't make sense. It's just a removal of a redundant instruction >> that simplifies driver code for me. So far nobody asked me to check >> IMM in drivers and keep the old codepath there. Yes, KILL_IF is silly, >> but it's a superset of both. >> > > MAD is a superset of MUL and ADD too. > (Ok maybe with precise that's not entirely true anymore, but I'm sure > you get the point.)
Yes, that's why r300 doesn't have MUL and ADD. Even though removing MUL and ADD might make sense in theory, I have no interest in that. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
