On Mon, Apr 16, 2018 at 6:45 AM, Erico Nunes <nunes.er...@gmail.com> wrote:
> 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? > Nope. That's kind of what the native_integers option is for. I'm just saying that it isn't incredibly well tested so be ware.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
