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
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

Reply via email to