On Tue, Oct 2, 2018 at 3:20 PM Marek Olšák <mar...@gmail.com> wrote:
> > On Tue, Oct 2, 2018, 1:15 PM Jason Ekstrand <ja...@jlekstrand.net> wrote: > >> Reading through things in a bit more detail, I do believe that importing >> this version in some form would be better than using mine for a number of >> reasons: >> >> * It is better optimized for signed integers >> * The struct of division factors is much better than what I did. (I did >> consider a struct and discarded the idea; I was wrong). >> * Computation of the division factors doesn't involve N*2-bit >> multiplication >> * The round-up algorithm here results in significantly better code than >> the N+1-bit round-down. >> * I trust ridiculousfish to get this right more than I trust myself >> >> That said, I have a few caveats on merging this as-is: >> >> * I would like to see some unit tests. I already spent the time to >> write some; they just have to be ported. >> * It needs to be adjusted to handle 64-bit integers (right now, it >> appears to only work for num_bits <= 32) >> * We shouldn't define uint_t and sint_t in a header >> >> How do you want to proceed? >> > > I don't have a plan. Anything that works for you would be OK with me, so > if you wanna just rework it according to you, that's fine. > I'm not in too much of a hurry but I can probably rework it if you don't get to it first. > Changing the types is tricky. Template code in a C header included several > times would work. C++ templates would be ideal. > We may be able to just s/uint_t/uint64_t/ for most of it. I *think* the functions to create the division parameters should fairly nicely generalize. It's the functions which actually do divisions that we'll have to re-type for each size. > What's your timeframe for this? Mine is certainly more than a month. > Unsure. I've got other (not the NIR pass) code pending that requires this and will hopefully be landing in a month or so. Sadly, I can't send it to the ML yet. In any case, I'd be looking at one to two months, probably. I'm happy for it to be a matter of whoever gets to it first. --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
