1. 15 Jun, 2018 1 commit
  2. 13 Jun, 2018 5 commits
    • Andrew Galante's avatar
      configure.ac: Test for __atomic_add_fetch in atomic checks · 87fb8bf6
      Andrew Galante authored
      Some platforms have 64-bit __atomic_load_n but not 64-bit
      __atomic_add_fetch, so test for both of them.
      
      Bug: https://bugs.gentoo.org/655616
      
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Reviewed-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      (cherry picked from commit baf16b2e)
      87fb8bf6
    • Andrew Galante's avatar
      meson: Test for __atomic_add_fetch in atomic checks · b9725e3a
      Andrew Galante authored
      Some platforms have 64-bit __atomic_load_n but not 64-bit
      __atomic_add_fetch, so test for both of them.
      
      Bug: https://bugs.gentoo.org/655616
      
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Reviewed-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      (cherry picked from commit 9d547a76)
      b9725e3a
    • Matt Turner's avatar
      meson: Fix -latomic check · 54b38ea4
      Matt Turner authored
      Commit 54ba73ef (configure.ac/meson.build: Fix -latomic test) fixed
      some checks for -latomic, and then commit 54bbe600 (configure.ac:
      rework -latomic check) further extended the fixes in configure.ac but
      not in Meson. This commit extends those fixes to the Meson tests.
      
      Fixes: 54bbe600
      
       (configure.ac: rework -latomic check)
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Reviewed-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      (cherry picked from commit b29b5a82)
      54b38ea4
    • Thomas Petazzoni's avatar
      configure.ac: rework -latomic check · f9500edb
      Thomas Petazzoni authored
      The configure.ac logic added in commit
      2ef7f238
      
       ("configure: check if
      -latomic is needed for __atomic_*") makes the assumption that if a
      64-bit atomic intrinsic test program fails to link without -latomic,
      it is because we must use -latomic.
      
      Unfortunately, this is not completely correct: libatomic only appeared
      in gcc 4.8, and therefore gcc versions before that will not have
      libatomic, and therefore don't provide atomic intrinsics for all
      architectures. This issue was for example encountered on PowerPC with
      a gcc 4.7 toolchain, where the build fails with:
      
      powerpc-ctng_e500v2-linux-gnuspe/bin/ld: cannot find -latomic
      
      This commit aims at fixing that, by not assuming -latomic is
      available. The commit re-organizes the atomic intrinsics detection as
      follows:
      
       (1) Test if a program using 64-bit atomic intrinsics links properly,
           without -latomic. If this is the case, we have atomic intrinsics,
           and we're good to go.
      
       (2) If (1) has failed, then test to link the same program, but this
           time with -latomic in LDFLAGS. If this is the case, then we have
           atomic intrinsics, provided we link with -latomic.
      
      This has been tested in three situations:
      
       - On x86-64, where atomic instrinsics are all built-in, with no need
         for libatomic. In this case, config.log contains:
      
         GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
         GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
         LIBATOMIC_LIBS=''
      
         This means: atomic intrinsics are available, and we don't need to
         link with libatomic.
      
       - On NIOS2, where atomic intrinsics are available, but some of them
         (64-bit ones) require using libatomic. In this case, config.log
         contains:
      
         GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
         GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
         LIBATOMIC_LIBS='-latomic'
      
         This means: atomic intrinsics are available, and we need to link
         with libatomic.
      
       - On PowerPC with an old gcc 4.7 toolchain, where 32-bit atomic
         instrinsics are available, but not 64-bit atomic instrinsics, and
         there is no libatomic. In this case, config.log contains:
      
         GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE=''
         GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='#'
      
         With means that atomic intrinsics are not usable.
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: Thomas Petazzoni's avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      (cherry picked from commit 54bbe600)
      f9500edb
    • Nicolas Boichat's avatar
      configure.ac/meson.build: Fix -latomic test · c001eceb
      Nicolas Boichat authored
      
      
      When compiling with LLVM 6.0 on x86 (32-bit) for Android, the test
      fails to detect that -latomic is actually required, as the atomic
      call is inlined.
      
      In the code itself (src/util/disk_cache.c), we see this pattern:
      p_atomic_add(cache->size, - (uint64_t)size);
      where cache->size is an uint64_t *, and results in the following
      link time error without -latomic:
      src/util/disk_cache.c:628: error: undefined reference to '__atomic_fetch_add_8'
      
      Fix the configure/meson test to replicate this pattern, which then
      correctly realizes the need for -latomic.
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      (cherry picked from commit 54ba73ef)
      c001eceb
  3. 12 Jun, 2018 2 commits
    • Dylan Baker's avatar
      cherry-ignore: Add another patch · d9c52794
      Dylan Baker authored
      d9c52794
    • Kenneth Graunke's avatar
      anv: Disable __gen_validate_value if NDEBUG is set. · 31c70b88
      Kenneth Graunke authored
      We were enabling undefined memory checking for genxml values based on
      Valgrind being installed at build time, even for release builds.  This
      generates piles and piles of assembly whenever you touch genxml.
      
      With gcc 7.3.1 and -O3 and -march=native on a Kabylake with Valgrind
      installed at build time:
      
            text    data    bss     dec    hex filename
         5978385  262884  13488 6254757 5f70a5 libvulkan_intel.so
         3799377  262884  13488 4075749 3e30e5 libvulkan_intel.so
      
      That's a 36% reduction in text size.
      
      Fixes: 047ed027
      
       (vk/emit: Use valgrind to validate every packed field)
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      (cherry picked from commit 0d5329d6)
      31c70b88
  4. 11 Jun, 2018 12 commits
  5. 08 Jun, 2018 3 commits
  6. 07 Jun, 2018 1 commit
    • Jason Ekstrand's avatar
      intel/blorp: Don't vertex fetch directly from clear values · cc4743a5
      Jason Ekstrand authored
      
      
      On gen8+, we have to VF cache flush whenever a vertex binding aliases a
      previous binding at the same index modulo 4GiB.  We deal with this in
      Vulkan by ensuring that vertex buffers and the dynamic state (from which
      BLORP pulls its vertex buffers) are in the same 4GiB region of the
      address space.  That doesn't work if we're reading clear colors with the
      VF unit.  In order to work around this we switch to using MI commands to
      copy the clear value into the vertex buffer we allocate for the normal
      constant data.
      
      Cc: mesa-stable@lists.freedesktop.org
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      (cherry picked from commit 44c61484)
      cc4743a5
  7. 06 Jun, 2018 3 commits
  8. 05 Jun, 2018 6 commits
  9. 04 Jun, 2018 4 commits
  10. 01 Jun, 2018 3 commits