1. 17 Sep, 2018 1 commit
    • Dylan Baker's avatar
      move pthread_setaffinity_np check to the build system · 3acc18fc
      Dylan Baker authored
      Rather than trying to encode all of the rules in a header, lets just put
      them in the build system where they belong. This fixes the build on
      FreeBSD, which does have pthraed_setaffinity_np, but it's in a
      pthread_np.h, not behind _GNU_SOURCE. FreeBSD also implements cpu_set
      slightly differently, so additional changes would be required to get it
      working right there anyway.
      
      v2: - fix #define in autotools
      
      Fixes: 9f1bbbdb
             ("util: try to fix the Android and MacOS build")
      Cc: Emil Velikov <emil.velikov@collabora.com>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      3acc18fc
  2. 24 Aug, 2018 1 commit
  3. 23 Aug, 2018 2 commits
  4. 20 Aug, 2018 1 commit
  5. 16 Aug, 2018 1 commit
  6. 08 Aug, 2018 4 commits
  7. 07 Aug, 2018 2 commits
  8. 03 Aug, 2018 2 commits
  9. 20 Jul, 2018 1 commit
  10. 12 Jul, 2018 1 commit
  11. 28 Jun, 2018 1 commit
  12. 21 Jun, 2018 2 commits
  13. 20 Jun, 2018 2 commits
    • Keith Packard's avatar
      vulkan: EXT_acquire_xlib_display requires libXrandr headers to build · 3f960c13
      Keith Packard authored
      When VK_USE_PLATFORM_XLIB_XRANDR_EXT is defined, vulkan.h includes
      X11/extensions/Xrandr.h for the RROutput typedef which is used in
      the vkGetRandROutputDisplayEXT interface.
      
      Make sure we have the required header by checking during the build,
      and also set CFLAGS to point at the right directory.
      
      We don't need to link against the library as we don't use any
      functions from there, so don't add the _LIBS value in the autotools
      build.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Fixes: dbac8e25 "radv: Add EXT_acquire_xlib_display to radv driver [v2]"
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      3f960c13
    • Gert Wollny's avatar
      configure.ac: Add CFLAG -Wno-missing-field-initializers (v5) · 81e5bf3c
      Gert Wollny authored
      This warning is misleading: When a struct is partially initialized without
      assigning to the structure members by name, then the remaining fields
      will be zeroed out, and this warning will be issued (if enabled). If, on the
      other hand, the partial initialization is done by assigning to named members,
      the remaining structure elements may hold random data, but the warning is not
      issued. Since in Mesa the first approach to initialize structure elements is
      used very often, and it is usually assumed that the remaining elements are
      zeroed out, heeding this warning would be counter-productive.
      
      v2: - add -Wno-missing-field-initializers to meson-build
          - fix empty line error
          (both Eric Engestrom)
      
      v3: * check for -Wmissing-field-initializers warning and then disable it
            because gcc and clang always accept -Wno-* (Dylan Baker)
          * Also disable this warning for C++
      
      v4: * meson.build add -Wno-missing-field-initializers to
            c_args instead of no_override_init_args (Eric Engstrom)
      
      v5: * configure.ac: Correct copy/paste error with CFLAGS/CXXFLAGS
      
      Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
      Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v2)
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@intel.com>
      Signed-off-by: Gert Wollny's avatarGert Wollny <gert.wollny@collabora.com>
      81e5bf3c
  14. 19 Jun, 2018 1 commit
    • Keith Packard's avatar
      vulkan: Add EXT_acquire_xlib_display [v5] · 7ab1fffc
      Keith Packard authored
      This extension adds the ability to borrow an X RandR output for
      temporary use directly by a Vulkan application. For DRM, we use the
      Linux resource leasing mechanism.
      
      v2:
      	Clean up xlib_lease detection
      
      	* Use separate temporary '_xlib_lease' variable to hold the
      	  option value to avoid changin the type of a variable.
      
      	* Use boolean expressions instead of additional if statements
      	  to compute resulting with_xlib_lease value.
      
      	* Simplify addition of VK_USE_PLATFORM_XLIB_XRANDR_KHR to
                vulkan_wsi_args
      Suggested-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@imgtec.com>
      
      	Move mode list from wsi_display to wsi_display_connector
      
      	Fix scope for wsi_display_mode and wsi_display_connector allocs
      Suggested-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      
      v3:
      	Adopt Jason Ekstrand's coding conventions
      
      	Declare variables at first use, eliminate extra whitespace
      	between types and names. Wrap lines to 80 columns.
      
      	Explicitly forbid multiple DRM leases. Making the code support
      	this looks tricky and will require additional thought.
      
      	Use xcb_randr_output_t throughout the internals of the
      	implementation. Convert at the public API
      	(wsi_get_randr_output_display).
      
      	Clean up check for usable active_crtc (possible when only the
      	desired output is connected to the crtc).
      Suggested-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      
      v4:
      	Move output resource fetching closer to use in
      	wsi_display_get_output. This simplifies the error returns in
      	earlier parts of the code a bit.
      
      	Return VK_ERROR_INITIALIZATION_FAILED from
      	wsi_acquire_xlib_display. Jason says this is the right error
      	message.
      Suggested-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      
      v5:
      	randr doesn't pass vscan over the wire, so we set vscan to 0
      	for randr-acquired modes, and test wsi modes for vscan <= 1
      	when comparing against randr modes.
      Suggested-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      7ab1fffc
  15. 17 Jun, 2018 1 commit
  16. 13 Jun, 2018 1 commit
  17. 08 Jun, 2018 1 commit
  18. 06 Jun, 2018 1 commit
  19. 05 Jun, 2018 1 commit
  20. 31 May, 2018 1 commit
    • D Scott Phillips's avatar
      util: Add a randomized test for the virtual memory allocator · 943fecc5
      D Scott Phillips authored
      The test pseudo-randomly makes allocations and deallocations with
      the virtual memory allocator and checks that the results are
      consistent. Specifically, we test that:
      
       * no result from the allocator overlaps an already allocated range
       * allocated memory fulfills the stated alignment requirement
       * a failed result from the allocator could not have been fulfilled
       * memory freed to the allocator can later be allocated again
      
      v2: - fix if() in test() to actually run fill()
      v3: - add c++11 build flag (Jason)
          - test the full 64-bit range (Jason)
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      943fecc5
  21. 17 May, 2018 3 commits
  22. 16 May, 2018 3 commits
  23. 15 May, 2018 2 commits
    • Rob Clark's avatar
      freedreno: fence should hold a ref to pipe · 273f7d84
      Rob Clark authored
      Since the fence can outlive the context, and all it really needs to wait
      on a fence is the pipe, use the new fd_pipe reference counting to hold a
      ref to the pipe and drop the ctx pointer.
      
      This fixes a crash seen with (for example) glmark2:
      
        #0  fd_pipe_wait_timeout (pipe=0xbf48678b3cd7b32b, timestamp=0, timeout=18446744073709551615) at freedreno_pipe.c:101
        #1  0x0000ffffbdf75914 in fd_fence_finish (pscreen=0x561110, ctx=0x0, fence=0xc55c10, timeout=18446744073709551615) at ../src/gallium/drivers/freedreno/freedreno_fence.c:96
        #2  0x0000ffffbde154e4 in dri_flush (cPriv=0xb1ff80, dPriv=0x556660, flags=3, reason=__DRI2_THROTTLE_SWAPBUFFER) at ../src/gallium/state_trackers/dri/dri_drawable.c:569
        #3  0x0000ffffbecd8b44 in loader_dri3_flush (draw=0x558a28, flags=3, throttle_reason=__DRI2_THROTTLE_SWAPBUFFER) at ../src/loader/loader_dri3_helper.c:656
        #4  0x0000ffffbecbc36c in glx_dri3_flush_drawable (draw=0x558a28, flags=3) at ../src/glx/dri3_glx.c:132
        #5  0x0000ffffbecd91e8 in loader_dri3_swap_buffers_msc (draw=0x558a28, target_msc=0, divisor=0, remainder=0, flush_flags=3, force_copy=false) at ../src/loader/loader_dri3_helper.c:827
        #6  0x0000ffffbecbcfc4 in dri3_swap_buffers (pdraw=0x5589f0, target_msc=0, divisor=0, remainder=0, flush=1) at ../src/glx/dri3_glx.c:587
        #7  0x0000ffffbec98218 in glXSwapBuffers (dpy=0x502bb0, drawable=2097154) at ../src/glx/glxcmds.c:840
        #8  0x000000000040994c in CanvasGeneric::update (this=0xfffffffff400) at ../src/canvas-generic.cpp:114
        #9  0x0000000000411594 in MainLoop::step (this=this@entry=0x5728f0) at ../src/main-loop.cpp:108
        #10 0x0000000000409498 in do_benchmark (canvas=...) at ../src/main.cpp:117
        #11 0x00000000004071b0 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.cpp:210
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      273f7d84
    • Thomas Hellstrom's avatar
      st/xa: Bump minor · 3d0b4979
      Thomas Hellstrom authored
      Bump xa minor to signal that the underlying mesa version is suitable for dri3.
      
      This is a bit ugly since it doesn't relate to a specific xa interface change.
      Recently there has been a number of fixes in mesa that helps enabling dri3
      without any significant regressions in automated testing and common desktop
      usage latency. However, the xf86-video-vmware driver has no other way to tell
      but inspecting the xa version.
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: Brian Paul's avatarBrian Paul <brianp@vmware.com>
      3d0b4979
  24. 10 May, 2018 1 commit
    • Thomas Petazzoni's avatar
      configure.ac: rework -latomic check · 54bbe600
      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: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      54bbe600
  25. 09 May, 2018 1 commit
    • Matt Turner's avatar
      configure.ac: Check for grep with AC_PROG_GREP · 00979402
      Matt Turner authored
      Perhaps with a new version of autoconf, I began seeing:
      
      | checking the name lister (/usr/bin/nm -B) interface... ./configure: line 6973: External.*some_variable: command not found
      | BSD nm
      
      This is because AC_PROG_NM expands to
      
      	...
      	if $GREP 'External.*some_variable' conftest.out > /dev/null; then
      	    lt_cv_nm_interface="MS dumpbin"
      	fi
      	...
      
      I'm not sure if it's a bug in AC_PROG_NM that it doesn't call
      AC_PROG_GREP, but it's easy enough for us to do it.
      00979402
  26. 07 May, 2018 1 commit
    • Nicolas Boichat's avatar
      configure.ac/meson.build: Fix -latomic test · 54ba73ef
      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>
      54ba73ef
  27. 30 Apr, 2018 1 commit