[Mesa-dev] [PATCH 09/22] nir/format_convert: Rename pack_r11g11b10f to pack_11f11f10f

[Jason Ekstrand]

On Fri, Aug 17, 2018 at 4:26 PM Roland Scheidegger <sroland at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180817/53695de8/attachment.html>