On Sun, Apr 15, 2018 at 2:30 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On April 14, 2018 12:43:35 Connor Abbott <cwabbo...@gmail.com> wrote: > I think that it's probably impractical to use this path, and we should > probably delete it. There are just too many optimizations, e.g. in > nir_opt_algebraic and lowering passes that assume you have ints. I > think a better plan would be to silently convert ints to floats in the > lima driver, and maybe inhibit any optimizations that use bit > twiddling tricks if real int support isn't indicated. > > I'm not sure. For quite a while prog_to_nir used these comparison > operations so we know they more it less work. For all I know, maybe it > still does (I didn't actually check). The only thing we need to worry about > in terms of correctness is any optimizations in nir_opt_algebraic which > consume only floats but produce integers. Also, all drivers need to handle > imov simply because it's easy. > > That being said, we've done a lot of work to optimize the integer supporting > paths so you may actually get better code if you can figure out a good way > to lower the integers away.
I'm not really using ints in my sample program, just floats. But still I'm getting nir_op_slt and nir_op_sge for the float comparison operations. Should I be getting nir_op_flt and nir_op_fge instead even with .native_integers disabled in glsl_to_nir? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
