1. 01 Jul, 2020 1 commit
  2. 30 Jun, 2020 1 commit
  3. 28 Jun, 2020 1 commit
  4. 16 Jun, 2020 1 commit
    • Jan Beich's avatar
      meson: unbreak sysctl.h detection on BSDs · 63b81c99
      Jan Beich authored
      Code:
       #include <sys/sysctl.h>
      Compiler stdout:
      
      Compiler stderr:
       In file included from testfile.c:1:
      /usr/include/sys/sysctl.h:1184:40: error: unknown type name 'size_t'
      int     sysctl(const int *, u_int, void *, size_t *, const void *, size_t);
                                                 ^
      /usr/include/sys/sysctl.h:1185:40: error: unknown type name 'size_t'
      int     sysctlbyname(const char *, void *, size_t *, const void *, size_t);
                                                 ^
      /usr/include/sys/sysctl.h:1186:42: error: unknown type name 'size_t'
      int     sysctlnametomib(const char *, int *, size_t *);
                                                   ^
      3 errors generated.
      
      Checking if "sys/sysctl.h" compiles: NO
      
      <drm@1f8ada80>
      <drm@4083e8f2>
      Reviewed-by: Niclas Zeising's avatarNiclas Zeising <zeising@daemonic.se>
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric@engestrom.ch>
      Cc: mesa-stable
      Part-of: <!5462>
      63b81c99
  5. 02 Jun, 2020 1 commit
  6. 01 Jun, 2020 5 commits
  7. 23 May, 2020 1 commit
  8. 21 May, 2020 1 commit
  9. 15 May, 2020 1 commit
  10. 24 Apr, 2020 1 commit
  11. 23 Apr, 2020 1 commit
    • Erik Faye-Lund 's avatar
      meson: correct windows-version define · 7f17a0a8
      Erik Faye-Lund authored
      The macro "_WINVER" does nothing, the macro definitions that matter for
      windows API version selection are "_WIN32_WINNT" and "WINVER".
      
      The header "sdkddkver.h" (which is included from thousands of
      different windows-headers) defines "WINVER" to the same value as
      "_WIN32_WINNT" of only the latter is defined, which explains why this
      works right now. But we shouldn't depend on that kind of luck, and
      instead define the right maco.
      
      Fixes: 3aee4627 ("meson: add windows compiler checks and libraries")
      Acked-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      Part-of: <!4681>
      7f17a0a8
  12. 21 Apr, 2020 1 commit
  13. 20 Apr, 2020 1 commit
    • Erik Faye-Lund 's avatar
      meson: do not disable incremental linking for debug-builds · d6b74396
      Erik Faye-Lund authored
      Meson specifies /EDITANDCONTINUE for MSVC projects when using the debug
      build-type. This collides with our across-the-board disabling of
      incremental linking.
      
      It's clear that we don't want to do incremental linking for
      release-builds; it increase the code-size, and adds some needless jumps
      to be able to patch in new code. But for debug-builds this seems like a
      good thing; we can now debug and on-the-fly recompile changes if we want
      to.
      
      This flag seems to have been simply forwarded from the SCons build
      system, where it makes a bit more sense; SCons doesn't really integrate
      with visual studio, so you can't properly debug with it. But Meson does,
      so let's keep some bells-and-whistles here.
      
      So let's avoid disabling incremental linking for debug-builds. For other
      builds we still want to do this, because Meson only disables it
      automatically for minsize-builds.
      
      This avoids a boat-loads of warnings on the form:
      
      warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
      Acked-by: Jose Fonseca's avatarJose Fonseca <jfonseca@vmware.com>
      Acked-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      Part-of: <!4572>
      d6b74396
  14. 16 Apr, 2020 2 commits
  15. 07 Apr, 2020 1 commit
  16. 30 Mar, 2020 2 commits
  17. 09 Mar, 2020 1 commit
  18. 02 Mar, 2020 1 commit
  19. 25 Feb, 2020 1 commit
  20. 18 Feb, 2020 1 commit
  21. 06 Feb, 2020 1 commit
  22. 05 Feb, 2020 1 commit
  23. 22 Jan, 2020 2 commits
  24. 02 Jan, 2020 1 commit
  25. 06 Dec, 2019 1 commit
  26. 26 Nov, 2019 1 commit
  27. 25 Nov, 2019 1 commit
  28. 23 Nov, 2019 2 commits
  29. 11 Nov, 2019 1 commit
    • Dylan Baker's avatar
      util: Use ZSTD for shader cache if possible · a8d94109
      Dylan Baker authored
      This allows ZSTD instead of ZLIB to be used for compressing the shader
      cache.
      
      On a 72 core system emulating skl with a full shader-db (with i965):
      ZSTD:
          1915.10s user 229.27s system 5150% cpu 41.632 total (cold cache)
          225.40s user 10.87s system 3810% cpu 6.201 total (warm cache)
          154M (235M on disk)
      ZLIB:
          2231.33s user 194.24s system 1899% cpu 2:07.72 total (cold cache)
          229.15s user 10.63s system 3906% cpu 6.139 total (warm cache)
          163M (244M on disk)
      
      Tim Arceri sees (8 core ryzen and a full shader-db):
      ZSTD:
          2505.22 user 40.50 system 3:18.73 elapsed 1280% CPU (cold cache)
          418.71 user 14.93 system 0:46.53 elapsed 931% CPU (warm cache)
          454.3 MB (681.7 MB on disk)
      ZLIB:
          3069.83 user 40.02 system 4:20.13 elapsed 1195% CPU (cold cache)
          425.50 user 15.17 system 0:46.80 elapsed 941% CPU (warm cache)
          470.3 MB (701.4 MB on disk)
      
      Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v1)
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      a8d94109
  30. 05 Nov, 2019 3 commits