1. 11 Jan, 2018 1 commit
  2. 28 Dec, 2017 1 commit
  3. 17 Dec, 2017 1 commit
  4. 08 Dec, 2017 3 commits
    • Jason Ekstrand's avatar
      anv: Enable UBO pushing · 4c7af87f
      Jason Ekstrand authored
      Push constants on Intel hardware are significantly more performant than
      pull constants.  Since most Vulkan applications don't actively use push
      constants on Vulkan or at least don't use it heavily, we're pulling way
      more than we should be.  By enabling pushing chunks of UBOs we can get
      rid of a lot of those pulls.
      
      On my SKL GT4e, this improves the performance of Dota 2 and Talos by
      around 2.5% and improves Aztec Ruins by around 2%.
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      4c7af87f
    • Jason Ekstrand's avatar
      anv/device: Increase the UBO alignment requirement to 32 · 8d340771
      Jason Ekstrand authored
      Push constants work in terms of 32-byte chunks so if we want to be able
      to push UBOs, every thing needs to be 32-byte aligned.  Currently, we
      only require 16-byte which is too small.
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      8d340771
    • Jason Ekstrand's avatar
      anv: Disable VK_KHR_16bit_storage · 597c1944
      Jason Ekstrand authored
      The testing for this extension is currently very poor.  The CTS tests
      only test accessing UBOs and SSBOs at dynamic offsets so none of our
      constant-offset paths get triggered at all.  Also, there's an assertion
      in our handling of nir_intrinsic_load_uniform that offset % 4 == 0 which
      is never triggered indicating that nothing every gets loaded from an
      offset which is not a dword.  Both push constants and the constant
      offset pull paths are complex enough, we really don't want to ship
      without tests.  We'll turn the extension back on once we have decent
      tests.
      597c1944
  5. 06 Dec, 2017 3 commits
  6. 04 Dec, 2017 4 commits
  7. 22 Nov, 2017 2 commits
  8. 13 Nov, 2017 1 commit
  9. 21 Oct, 2017 1 commit
  10. 18 Oct, 2017 2 commits
    • Vinson Lee's avatar
      anv: Fix instance typos. · c5124fbc
      Vinson Lee authored
      Fix build error.
      
        CC       vulkan/vulkan_libvulkan_common_la-anv_device.lo
      In file included from vulkan/anv_device.c:33:0:
      vulkan/anv_device.c: In function ‘anv_AllocateMemory’:
      vulkan/anv_device.c:1562:37: error: ‘struct anv_device’ has no member named ‘instace’; did you mean ‘instance’?
                result = vk_errorf(device->instace, device,
                                           ^
      vulkan/anv_private.h:317:17: note: in definition of macro ‘vk_errorf’
           __vk_errorf(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
                       ^~~~~~~~
      
      Fixes: 9775894f ("anv: Move size check from anv_bo_cache_import() to caller (v2)")
      Signed-off-by: Vinson Lee's avatarVinson Lee <vlee@freedesktop.org>
      Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric.engestrom@imgtec.com>
      c5124fbc
    • chadversary's avatar
      anv: Move size check from anv_bo_cache_import() to caller (v2) · 9775894f
      chadversary authored
      This change prepares for VK_ANDROID_native_buffer. When the user imports
      a gralloc hande into a VkImage using VK_ANDROID_native_buffer, the user
      provides no size. The driver must infer the size from the internals of
      the gralloc buffer.
      
      The patch is essentially a refactor patch, but it does change behavior
      in some edge cases, described below. In what follows, the "nominal size"
      of the bo refers to anv_bo::size, which may not match the bo's "actual
      size" according to the kernel.
      
      Post-patch, the nominal size of the bo returned from
      anv_bo_cache_import() is always the size of imported dma-buf according
      to lseek(). Pre-patch, the bo's nominal size was difficult to predict.
      If the imported dma-buf's gem handle was not resident in the cache, then
      the bo's nominal size was align(VkMemoryAllocateInfo::allocationSize,
      4096).  If it *was* resident, then the bo's nominal size was whatever
      the cache returned. As a consequence, the first cache insert decided the
      bo's nominal size, which could be significantly smaller compared to the
      dma-buf's actual size, as the nominal size was determined by
      VkMemoryAllocationInfo::allocationSize and not lseek().
      
      I believe this patch cleans up that messy behavior. For an imported or
      exported VkDeviceMemory, anv_bo::size should now be the true size of the
      bo, if I correctly understand the problem (which I possibly don't).
      
      v2:
        - Preserve behavior of aligning size to 4096 before checking. [for
          jekstrand]
        - Check size with < instead of <=, to match behavior of commit c0a4f56f
          "anv: bo_cache: allow importing a BO larger than needed". [for
          chadv]
      9775894f
  11. 17 Oct, 2017 2 commits
    • chadversary's avatar
      anv: Move close(fd) from anv_bo_cache_import to its callers (v2) · eb69a618
      chadversary authored
      This will allow us to implement VK_ANDROID_native_buffer without dup'ing
      the fd. We must close the fd in VK_KHR_external_memory_fd, but we should
      not in VK_ANDROID_native_buffer.
      
      v2:
        - Add missing close(fd) for case
          VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR, subcase
          ANV_SEMAPHORE_TYPE_BO.
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      eb69a618
    • chadversary's avatar
      anv: Better support for Android logging (v2) · a9ca8f37
      chadversary authored
      In src/intel/vulkan/*, redirect all instances of printf, vk_error,
      anv_loge, anv_debug, anv_finishme, anv_perf_warn, anv_assert, and their
      many variants to the new intel_log functions. I believe I caught them
      all.
      
      The other subdirs of src/intel are left for a future exercise.
      
      v2:
        - Rebase onto Tapani's VK_EXT_debug_report changes.
        - Drop unused #include <cutils/log.h>.
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      a9ca8f37
  12. 13 Oct, 2017 1 commit
  13. 06 Oct, 2017 1 commit
  14. 21 Sep, 2017 1 commit
  15. 18 Sep, 2017 1 commit
  16. 13 Sep, 2017 1 commit
    • chadversary's avatar
      util: Query build-id by symbol address, not library name · 5c98d382
      chadversary authored
      This patch renames build_id_find_nhdr() to
      build_id_find_nhdr_for_addr(), and changes it to never examine the
      library name.
      
      Tested on Fedora by confirming that build_id_get_data() returns the same
      build-id as the file(1) tool. For BSD, I confirmed that the API used
      (dladdr() and struct Dl_info) is documented in FreeBSD's manpages.
      
      This solves two problems:
      
          - We can now the query the build-id without knowing the installed library's
            filename.
      
            This matters because Android requires specific filenames for HAL
            modules, such as "/vendor/lib/hw/vulkan.${board}.so". The HAL
            filenames do not follow the Unix convention of "libfoo.so".  In
            other words, the same query code will now work on Linux and Android.
      
          - Querying the build-id now works correctly when the process
            contains multiple shared objects with the same basename.
            (Admittedly, this is a highly unlikely scenario).
      
      Cc: Jonathan Gray <jsg@jsg.id.au>
      Reviewed-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      5c98d382
  17. 12 Sep, 2017 4 commits
  18. 29 Aug, 2017 1 commit
  19. 16 Aug, 2017 3 commits
  20. 02 Aug, 2017 1 commit
  21. 01 Aug, 2017 1 commit
    • Jason Ekstrand's avatar
      anv: Autogenerate extension query and lookup · d62063ce
      Jason Ekstrand authored
      As time goes on, extension advertising is going to get more complex.
      Today, we either implement an extension or we don't.  However, in the
      future, whether or not we advertise an extension will depend on kernel
      or hardware features.  This commit introduces a python codegen framework
      that generates the anv_EnumerateFooExtensionProperties functions as well
      as a pair of anv_foo_extension_supported functions for querying for the
      support of a given extension string.  Each extension has an "enable"
      predicate that is any valid C expression.  For device extensions, the
      physical device is available as "device" so the expression could be
      something such as "device->has_kernel_feature".  For instance
      extensions, the only option is VK_USE_PLATFORM defines.
      
      This mechanism also means that we have a single one-line-per-entry table
      for all extension declarations instead of the two tables we had in
      anv_device.c and the one we had in anv_entrypoints_gen.py.  The Python
      code is smart and uses the XML to determine whether an extension is an
      instance extension or device extension.
      Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      d62063ce
  22. 18 Jul, 2017 2 commits
  23. 17 Jul, 2017 2 commits