[Mesa-dev] [PATCH] nir: fix ir_binop_gequal glsl_to_nir conversion
Jason Ekstrand
jason at jlekstrand.net
Mon Apr 16 14:55:34 UTC 2018
On Mon, Apr 16, 2018 at 6:45 AM, Erico Nunes <nunes.erico at gmail.com> wrote:
> On Sun, Apr 15, 2018 at 2:30 AM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> > On April 14, 2018 12:43:35 Connor Abbott <cwabbott0 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180416/876c00b3/attachment.html>
More information about the mesa-dev
mailing list