anv: Do relocations in userspace before execbuf ioctl

Since our surface state buffer is shared by all batches, the kernel does a
full stall and sync with the CPU between batches every time we call
execbuf2 because it refuses to do relocations on an active buffer.  Doing
them in userspace and passing the NO_RELOC flag to the kernel allows us to
perform the relocations without stalling.

This improves the performance of Dota 2 by around 30% on a Sky Lake GT2.

v2 (Jason Ekstrand):
 - Better comments (Chris Wilson)
 - Fixed write_reloc for correct canonical form (Chris Wilson)

v3 (Jason Ekstrand):
 - Skip relocations which aren't needed
 - Provide an environment variable to always use the kernel
 - More comments about correctness (Chris Wilson)

v4 (Jason Ekstrand):
 - More comments (Chris Wilson)

v5 (Jason Ekstrand):
 - Rebase on top of moving execbuf2 setup go QueueSubmit

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

src/intel/vulkan/anv_device.c

@@ -1097,7 +1097,7 @@ VkResult anv_QueueSubmit(
    struct anv_device *device = queue->device;
    VkResult result = VK_SUCCESS;
 
-   /* We lock around QueueSubmit for two main reasons:
+   /* We lock around QueueSubmit for three main reasons:
     *
     *  1) When a block pool is resized, we create a new gem handle with a
     *     different size and, in the case of surface states, possibly a
@@ -1112,6 +1112,12 @@ VkResult anv_QueueSubmit(
     *     came up in the wild due to a broken app.  It's better to play it
     *     safe and just lock around QueueSubmit.
     *
+    *  3)  The anv_cmd_buffer_execbuf function may perform relocations in
+    *      userspace.  Due to the fact that the surface state buffer is shared
+    *      between batches, we can't afford to have that happen from multiple
+    *      threads at the same time.  Even though the user is supposed to
+    *      ensure this doesn't happen, we play it safe as in (2) above.
+    *
     * Since the only other things that ever take the device lock such as block
     * pool resize only rarely happen, this will almost never be contended so
     * taking a lock isn't really an expensive operation in this case.