On Sun, Aug 20, 2017 at 6:51 AM, Marek Olšák <mar...@gmail.com> wrote: > On Sun, Aug 20, 2017 at 4:29 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> For 1-3/8, I don't think anything ever used these, and 5/8 (DPH) we >> don't need neither, so >> Reviewed-by: Roland Scheidegger <srol...@vmware.com> >> >> 4,6,7, well we can live fine without them, just translating them away >> the same as you do here too. (I thought some hw could do them natively, >> hence the driver would have to recognize them to get optimal results, >> but if they aren't emitted anyway who cares.) >> >> Can we keep KILL though please? From a shader api cleanness point of >> view, I'd rather have this simple instruction than upgrading it to a >> rather complex instruction involving per-channel float comparisons (plus >> combining the results), even if it's trivial to do so and the compiler >> should be able to throw out all the conditional mess. >> From a conceptual point of view, we don't have conditional ret, cont, >> etc. neither (much less ones which use built-in per channel float >> comparisons...). Probably nuking KILL_IF instead isn't a good idea (as >> this really translates to old-style kill) so IMHO we should just keep both. >> (But you can really kill breakc if you want - that's going to be less >> work than any of the dp2a/xpd/scs ones here :-)). > > Yeah, I can keep KILL and then kill BREAKC. > > XPD etc. were really trivial. There is only one or two places that > need to unwind the instructions. The rest is just removed code.
I can't say I care *strongly*, but some of those DP* variants have hw instructions that correspond both in nv30 and r300, and I believe neither have the compilers to properly recombine them. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
