On Fri, Aug 17, 2018 at 4:26 PM Roland Scheidegger <srol...@vmware.com>
wrote:
> Am 17.08.2018 um 22:06 schrieb Jason Ekstrand:
> > This matches the unpack function.
> > ---
> > src/compiler/nir/nir_format_convert.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_format_convert.h
> b/src/compiler/nir/nir_format_convert.h
> > index 75793733ea6..c79001a50aa 100644
> > --- a/src/compiler/nir/nir_format_convert.h
> > +++ b/src/compiler/nir/nir_format_convert.h
> > @@ -298,7 +298,7 @@ nir_format_unpack_11f11f10f(nir_builder *b,
> nir_ssa_def *packed)
> > }
> >
> > static inline nir_ssa_def *
> > -nir_format_pack_r11g11b10f(nir_builder *b, nir_ssa_def *color)
> > +nir_format_pack_11f11f10f(nir_builder *b, nir_ssa_def *color)
> > {
> > /* 10 and 11-bit floats are unsigned. Clamp to non-negative */
> > nir_ssa_def *clamped = nir_fmax(b, color, nir_imm_float(b, 0));
> >
>
> Not that this is actually changing with this patch, I just saw it by
> accident - but fmax will kill off NaNs, despite that this format can
> encode them easily.
>
True. If we're concerned about that, we could always replace it with
"color = color <= 0 ? 0 : color" then a NaN would be propagated. At
current, I think the optimizer is likely to detect that and replace it with
fmax though....
> I suppose though that's ok for GL...
>
Yeah. Thanks for pointing it out though!
--Jason
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
