1. 30 Jul, 2019 3 commits
    • Connor Abbott's avatar
      lima/gp: Support exp2 and log2 · 11a49f28
      Connor Abbott authored
      log2 is tricky because there cannot be a move between complex1 and
      postlog2. We can't guarantee that scheduling complex1 will succeed when
      we schedule postlog2, so we try to schedule complex1 and if it fails we
      back out by rewriting the postlog2 as a move and introducing a new
      postlog2 so that we can try again later.
      Signed-off-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
      Acked-by: Qiang Yu's avatarQiang Yu <yuq825@gmail.com>
    • Connor Abbott's avatar
      lima/gpir: Always schedule complex2 and *_impl right after complex1 · c2f48d8f
      Connor Abbott authored
      See lima/mesa#94
       for the gory
      details of why this is needed. For *_impl this is easy, since it never
      increases register pressure and it goes in the complex slot hence it
      never counts against max nodes. It's a bit more challenging for
      complex2, since it does count against max nodes, so we need to change
      the reservation logic to reserve an extra slot for complex2 when
      scheduling complex1. This second part isn't strictly necessary yet, but
      it will be for exp2.
      Signed-off-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
      Acked-by: Qiang Yu's avatarQiang Yu <yuq825@gmail.com>
    • Bas Nieuwenhuizen's avatar
      radv: Fix descriptor set allocation failure. · 2b53c49d
      Bas Nieuwenhuizen authored
      Set all the handles to VK_NULL_HANDLE:
      "If the creation of any of those descriptor sets fails, then the implementation
      must destroy all successfully created descriptor set objects from this command,
      set all entries of the pDescriptorSets array to VK_NULL_HANDLE and return the
      (Vulkan 1.1.117 Spec, section 13.2)
      CC: <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
  2. 27 Jul, 2019 1 commit
    • Andres Rodriguez's avatar
      radv: fix queries with WAIT_BIT returning VK_NOT_READY · 2b71b4e7
      Andres Rodriguez authored
      When vkGetQueryPoolResults() is called with VK_QUERY_RESULT_WAIT_BIT
      set, the driver is supposed to wait for the query to become available
      before returning.
      Currently, radv returns once the query is indeed ready, but it returns
      VK_NOT_READY. It also fails to populate the results.
      The problem is a missing volatile in the secondary check for query
      availability. This patch removes the secondary check altogether since it
      is redundant with the preceding loop.
      This bug was found with an unreleased version of SteamVR.
      Reviewed-by: Bas Nieuwenhuizen's avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
  3. 30 Jul, 2019 36 commits