[Mesa-dev] [PATCH 0/9] nir: Add better helpers for handling constant sources

Mon Oct 22 15:14:26 UTC 2018

Re: The list.

It doesn't always happen every month, but I've seen it multiple times now,
as far back as January 2018, though possibly earlier.

The gzip mail archive however has all the messages that are missing from
the web archive.
https://lists.freedesktop.org/archives/mesa-dev/2018-October.txt.gz

There are patches in that series missing however, as you pointed out.

That said, looking at that file I see that the last message that didn't get
processed had the following Message ID header:

Message-ID: <20181020175547.9159-6-jason.ekstrand at intel.com>

The messages are a bit out of order there, which may or may not be related.
I can't see anything else that seems out of the ordinary.

I also get DMARC issues for certain emails (they fail DMARC, meaning that
they've not been handled properly when passing through the list). I notice
this particularly for emails from Liviu Prodea liviuprodea at yahoo.com but
sometimes for other ppl too.

Perhaps a later version of Mailman (eg: 2.1.29?) might resolve some/both of
these issues?

On Mon, 22 Oct 2018 at 22:31, Samuel Iglesias Gonsálvez <
siglesias at igalia.com> wrote:

> Patch 7/9 has never arrived my inbox and checking the archives [0], looks
> like
> the archive is messed up... it has only a few emails. Does somebody know
> what
> happened with the ML archive?
>
> Sam
>
> [0] https://lists.freedesktop.org/archives/mesa-dev/2018-October/date.html
>
> On Saturday, 20 October 2018 19:55:38 (CEST) Jason Ekstrand wrote:
> > Previously, the only thing we had was nir_src_as_const_value which
> returns
> > a pointer to a nir_const_value which was NULL if the source wasn't
> actually
> > a constant.  This was great except that almost none of the users
> considered
> > anything other than 32-bit values.  With 8, 16, and 64-bit values
> floating
> > around, we really shouldn't be hand-rolling it everywhere.  Most of the
> > code is currently safe if you operate under the assumption that things
> like
> > array indices are always 32 bits.  The glaring exception was some of the
> > helpers in nir_search_helpers.h where we definitely cannot be making that
> > assumption but were anyway.
> >
> > I've converted core NIR and i965 but have not written patches for vc4,
> ir3,
> > or radeon.
> >
> > Cc: Connor Abbott <cwabbott0 at gmail.com>
> > Cc: Timothy Arceri <tarceri at itsqueeze.com>
> > Cc: Eric Anholt <eric at anholt.net>
> > Cc: Rob Clark <robdclark at gmail.com>
> > Cc: Karol Herbst <karolherbst at gmail.com>
> > Cc: Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
> >
> > Jason Ekstrand (9):
> >   nir: Add some new helpers for working with const sources
> >   nir/search: Use nir_src_is_const and friends
> >   nir/search_helpers: Use nir_src_is_const and friends
> >   nir: Use nir_src_is_const and nir_src_as_* in core code
> >   intel/fs,vec4: Clean up a repeated pattern with SSBOs
> >   intel/fs: Use the new nir_src_is_const and friends
> >   intel/vec4: Use the new nir_src_is_const and friends
> >   intel/analyze_ubo_ranges: Use nir_src_is_const and friends
> >   anv: Use nir_src_is_const and friends in lowering code
> >
> >  src/compiler/glsl/gl_nir_lower_samplers.c     |   7 +-
> >  src/compiler/nir/nir.c                        |  92 +++++
> >  src/compiler/nir/nir.h                        |  16 +
> >  src/compiler/nir/nir_deref.c                  |  14 +-
> >  src/compiler/nir/nir_gather_info.c            |   6 +-
> >  src/compiler/nir/nir_gs_count_vertices.c      |   7 +-
> >  src/compiler/nir/nir_lower_clip.c             |   2 +-
> >  src/compiler/nir/nir_lower_indirect_derefs.c  |   4 +-
> >  src/compiler/nir/nir_lower_io.c               |   6 +-
> >  .../nir/nir_lower_io_arrays_to_elements.c     |  11 +-
> >  src/compiler/nir/nir_lower_locals_to_regs.c   |   6 +-
> >  src/compiler/nir/nir_lower_two_sided_color.c  |   2 +-
> >  src/compiler/nir/nir_lower_vars_to_ssa.c      |  14 +-
> >  src/compiler/nir/nir_opt_dead_cf.c            |   7 +-
> >  src/compiler/nir/nir_opt_find_array_copies.c  |  13 +-
> >  src/compiler/nir/nir_opt_intrinsics.c         |   4 +-
> >  src/compiler/nir/nir_opt_large_constants.c    |   2 +-
> >  src/compiler/nir/nir_search.c                 |  70 +---
> >  src/compiler/nir/nir_search_helpers.h         |  49 ++-
> >  src/compiler/nir/nir_split_vars.c             |  17 +-
> >  src/compiler/nir/tests/vars_tests.cpp         |  10 +-
> >  src/intel/compiler/brw_fs.h                   |   2 +
> >  src/intel/compiler/brw_fs_nir.cpp             | 315 +++++++-----------
> >  .../compiler/brw_nir_analyze_ubo_ranges.c     |  15 +-
> >  src/intel/compiler/brw_vec4.h                 |   2 +
> >  src/intel/compiler/brw_vec4_gs_nir.cpp        |  12 +-
> >  src/intel/compiler/brw_vec4_nir.cpp           | 190 ++++-------
> >  src/intel/compiler/brw_vec4_tcs.cpp           |   6 +-
> >  .../vulkan/anv_nir_apply_pipeline_layout.c    |  15 +-
> >  .../vulkan/anv_nir_lower_ycbcr_textures.c     |   6 +-
> >  30 files changed, 423 insertions(+), 499 deletions(-)
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

-- 
Stuart Young (aka Cefiar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181023/953f8429/attachment-0001.html>