1. 29 Apr, 2019 1 commit
  2. 25 Apr, 2019 3 commits
  3. 22 Apr, 2019 1 commit
  4. 19 Apr, 2019 1 commit
    • Bas Nieuwenhuizen's avatar
      radv: Support VK_EXT_inline_uniform_block. · 8d2654a4
      Bas Nieuwenhuizen authored
      Basically just reserve the memory in the descriptor sets.
      
      On the shader side we construct a buffer descriptor, since
      AFAIU VGPR indexing on 32-bit pointers in LLVM is still broken.
      
      This fully supports update after bind and variable descriptor set
      sizes. However, the limits are somewhat arbitrary and are mostly
      about finding a reasonable division of a 2 GiB max memory size over
      the set.
      
      v2: - rebased on top of master (Samuel)
          - remove the loading resources rework (Samuel)
          - only load UBO descriptors if it's a pointer (Samuel)
          - use LLVMBuildPtrToInt to avoid IR failures (Samuel)
      
      Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (v2)
      8d2654a4
  5. 17 Apr, 2019 1 commit
  6. 16 Apr, 2019 1 commit
  7. 10 Apr, 2019 1 commit
  8. 01 Apr, 2019 1 commit
  9. 28 Mar, 2019 1 commit
  10. 21 Mar, 2019 1 commit
  11. 20 Mar, 2019 1 commit
  12. 18 Mar, 2019 2 commits
  13. 20 Feb, 2019 1 commit
  14. 06 Feb, 2019 1 commit
  15. 29 Jan, 2019 1 commit
  16. 27 Jan, 2019 1 commit
    • Niklas Haas's avatar
      radv: add device->instance extension dependencies · 804cc44d
      Niklas Haas authored
      
      
      From the vulkan spec 33.3 "Extension Dependencies":
      
      "Any device extension that has an instance extension dependency that is
      not enabled by vkCreateInstance is considered to be unsupported, hence
      it must not be returned by vkEnumerateDeviceExtensionProperties for any
      VkPhysicalDevice child of the instance."
      
      Therefore we need to check whether the instance-level extensions are
      actually enabled when deciding to support a device-level extension or
      not.
      
      Furthermore, we need to do this for all instance-level extensions of any
      (transitive) device-level extension dependency, due to the following
      paragraph:
      
      "If an extension is supported (as queried by
      vkEnumerateInstanceExtensionProperties or
      vkEnumerateDeviceExtensionProperties), then required extensions of that
      extension must also be supported for the same instance or physical
      device."
      
      Finally, because some of these vulkan extensions may be implicitly
      promoted to future vulkan core API versions, we can also satisfy the
      dependency if the vulkan API version is high enough.
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      804cc44d
  17. 15 Jan, 2019 1 commit
  18. 17 Dec, 2018 2 commits
  19. 12 Dec, 2018 1 commit
  20. 11 Dec, 2018 1 commit
    • Jason Ekstrand's avatar
      anv,radv: Disable VK_EXT_pci_bus_info · 8f401b0c
      Jason Ekstrand authored
      
      
      The Vulkan working group recently discovered that we made a mistake in
      assuming that PCI domains are 16-bit even though they can potentially be
      32-bit values.  To fix this, the next spec update will change the types
      in the VK_EXT_pci_bus_info struct to be 32 bits which will be a
      backwards-incompatible change.  Normally, Khronos tries very hard to
      never make backwards incompatible changes to specs.  Hopefully, the
      extension is new enough (2 months) that there are no shipping apps which
      use the extension so this should be safe.
      
      This commit disables the extension for both anv and radv in mesa and
      should be back-ported to 18.3 ASAP so we avoid any potential issues with
      new apps running on old drivers.  I'll send out a commit (which we can
      also back-port to 18.3 if we really care) to re-enable the extension in
      both drivers once this week's spec update ships.  The one known use of
      this extension is internal to mesa and will continue working with the
      extension disabled and will naturally update when we get a new header.
      
      Cc: "18.3" <mesa-stable@lists.freedesktop.org>
      Acked-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Acked-by: Samuel Pitoiset's avatarSamuel Pitoiset <samuel.pitoiset@gmail.com>
      8f401b0c
  21. 06 Dec, 2018 1 commit
  22. 05 Dec, 2018 1 commit
  23. 29 Oct, 2018 1 commit
  24. 25 Oct, 2018 1 commit
  25. 22 Oct, 2018 1 commit
  26. 18 Oct, 2018 1 commit
  27. 15 Oct, 2018 1 commit
  28. 18 Sep, 2018 1 commit
  29. 10 Sep, 2018 1 commit
  30. 14 Aug, 2018 1 commit
  31. 07 Aug, 2018 1 commit
    • Mathieu Bridon's avatar
      python: Fix rich comparisons · e1b88aee
      Mathieu Bridon authored
      
      
      Python 3 doesn't call objects __cmp__() methods any more to compare
      them. Instead, it requires implementing the rich comparison methods
      explicitly: __eq__(), __ne(), __lt__(), __le__(), __gt__() and __ge__().
      
      Fortunately Python 2 also supports those.
      
      This commit only implements the comparison methods which are actually
      used by the build scripts.
      Signed-off-by: Mathieu Bridon's avatarMathieu Bridon <bochecha@daitauha.fr>
      Reviewed-by: Dylan Baker's avatarDylan Baker <dylan@pnwbakers.com>
      e1b88aee
  32. 23 Jul, 2018 1 commit
  33. 18 Jul, 2018 1 commit
  34. 12 Jul, 2018 1 commit
  35. 10 Jul, 2018 1 commit
  36. 26 Jun, 2018 1 commit