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

Reply via email to