Attachment 130985 Details for Bug 100620 – Patch to fix 48-bit issues with scratch buffers

[patch] Patch to fix 48-bit issues with scratch buffers

0001-anv-Don-t-place-scratch-buffers-above-the-32-bit-bou.patch (text/plain), 2.00 KB, created by Jason Ekstrand on 2017-04-22 22:54:25 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jason Ekstrand

Created: 2017-04-22 22:54:25 UTC

Size: 2.00 KB

patch

obsolete

>From a14db300d9a4e53247fe4f4911666e2ae93ee361 Mon Sep 17 00:00:00 2001
>From: Jason Ekstrand <jason.ekstrand@intel.com>
>Date: Sat, 22 Apr 2017 15:51:01 -0700
>Subject: [PATCH] anv: Don't place scratch buffers above the 32-bit boundary
>
>This fixes rendering corruptions in DOOM.  Hopefully, it will also make
>Jenkins a bit more stable as we've been seeing some random failures and
>GPU hangs ever since turning on 48bit.
>
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100620
>Cc: "17.1" <mesa-stable@lists.freedesktop.org>
>---
> src/intel/vulkan/anv_allocator.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
>diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
>index 78327df..28bfac4 100644
>--- a/src/intel/vulkan/anv_allocator.c
>+++ b/src/intel/vulkan/anv_allocator.c
>@@ -994,6 +994,22 @@ anv_scratch_pool_alloc(struct anv_device *device, struct anv_scratch_pool *pool,
> 
>    anv_bo_init_new(&bo->bo, device, size);
> 
>+   /* Even though the Scratch base pointers in 3DSTATE_*S are 64 bits, they
>+    * are still relative to the general state base address.  When we emit
>+    * STATE_BASE_ADDRESS, we set general state base address to 0 and the size
>+    * to the maximum (1 page under 4GB).  This allows us to just place the
>+    * scratch buffers anywhere we wish in the bottom 32 bits of address space
>+    * and just set the scratch base pointer in 3DSTATE_*S using a relocation.
>+    * However, in order to do so, we need to ensure that the kernel does not
>+    * place the scratch BO above the 32-bit boundary.
>+    *
>+    * NOTE: Technically, it can't go "anywhere" because the top page is off
>+    * limits.  However, it will never end up getting placed that high because
>+    * the surface state and general state buffers will get placed first and
>+    * the kernel likes to work top-down.
>+    */
>+   bo->bo.flags &= ~EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
>+
>    /* Set the exists last because it may be read by other threads */
>    __sync_synchronize();
>    bo->exists = true;
>-- 
>2.5.0.400.gff86faf
>

Actions: View | Splinter Review

Attachments on bug 100620: 130758 | 130760 | 130761 | 130764 | 130801 | 130802 | 130803 | 130805 | 130985

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.