mesa: Backport tu/autotune and reg_size_vec4 fixes for a702

recipes-graphics/mesa/mesa.bbappend

@@ -1,9 +1,11 @@
 FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
 
-SRC_URI:append:qcom = " \ 
+SRC_URI:append:qcom = " \
     file://0001-freedreno-Add-support-for-A704.patch \
     file://0001-freedreno-layout-tu-Fix-UBWC-block-sizes-for-PIPE_FO.patch \
     file://0001-freedreno-Modify-reg_size_vec4-for-a608-and-a612-to-32.patch \
+    file://0001-tu-autotune-Disable-autotuning-for-small-renderpasse.patch \
+    file://0001-freedreno-Increase-reg_size_vec4-for-A702.patch \
 "
 
 # Enable freedreno driver

recipes-graphics/mesa/mesa/0001-freedreno-Increase-reg_size_vec4-for-A702.patch

@@ -0,0 +1,35 @@
+From e63bbb794fd7935e8a5d0d7f7fe9c05e65d990f8 Mon Sep 17 00:00:00 2001
+From: Valentine Burley <valentine.burley@collabora.com>
+Date: Thu, 16 Jul 2026 08:08:45 +0200
+Subject: [PATCH] freedreno: Increase reg_size_vec4 for A702
+
+A702 was inheriting reg_size_vec4 = 48 from a6xx_gen1_low, which was
+sized for A610's 64-thread wave. A702 uses a 16-thread wave, so the
+inherited value underestimated the capacity the compiler should assume
+per wave.
+
+Upstream-Status: Backport [https://gitlab.freedesktop.org/mesa/mesa/-/commit/6a282e8f18a16c3445ce3498ecd5c09667e97555]
+
+Fixes: 639d7946c71 ("freedreno: Add initial A702 support")
+Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
+Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43038>
+---
+ src/freedreno/common/freedreno_devices.py |   1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 src/freedreno/ci/freedreno-a702-fails.txt
+
+diff --git a/src/freedreno/common/freedreno_devices.py b/src/freedreno/common/freedreno_devices.py
+index 742fd1f1df9..8e51e07f23c 100644
+--- a/src/freedreno/common/freedreno_devices.py
++++ b/src/freedreno/common/freedreno_devices.py
+@@ -893,6 +893,7 @@ add_gpus([
+     ], A6xxGPUInfo(
+         CHIP.A6XX, # NOT a mistake!
+         [a6xx_base, a6xx_gen1_low, GPUProps(
++            reg_size_vec4 = 64,
+             has_cp_reg_write = False,
+             has_gmem_fast_clear = True,
+             sysmem_per_ccu_depth_cache_size = 8 * 1024, # ??????
+-- 
+2.43.0
+

recipes-graphics/mesa/mesa/0001-tu-autotune-Disable-autotuning-for-small-renderpasse.patch

@@ -0,0 +1,39 @@
+From c6d56654a06038c93b8ad8d8e9ad98de072d0465 Mon Sep 17 00:00:00 2001
+From: Dhruv Mark Collins <mark@igalia.com>
+Date: Thu, 9 Oct 2025 13:56:46 +0000
+Subject: [PATCH] tu/autotune: Disable autotuning for small renderpasses by
+ default
+
+Tuning these small renderpasses is difficult due to their high
+variability across command buffers and low impact on overall performance
+in most cases. This change disables autotuning for renderpasses with
+fewer than 5 draw calls.
+
+Upstream-Status: Backport [https://gitlab.freedesktop.org/mesa/mesa/-/commit/bf2777c0130954f969c5a1038a01f94ec2d1ac63]
+Signed-off-by: Dhruv Mark Collins <mark@igalia.com>
+---
+ src/freedreno/vulkan/tu_autotune.cc | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/src/freedreno/vulkan/tu_autotune.cc b/src/freedreno/vulkan/tu_autotune.cc
+index df969834a37..3fb1f0f7cae 100644
+--- a/src/freedreno/vulkan/tu_autotune.cc
++++ b/src/freedreno/vulkan/tu_autotune.cc
+@@ -579,6 +579,14 @@ tu_autotune_use_bypass(struct tu_autotune *at,
+    if (!at->enabled || simultaneous_use)
+       return fallback_use_bypass(pass, framebuffer, cmd_buffer);
+
++   /* These smaller RPs with few draws are too difficult to create a balanced hash for that can independently identify
++    * them while not being so unique to not properly identify them across CBs. They're generally insigificant outside of
++    * a few edge cases such as during deferred rendering G-buffer passes, as we don't have a good way to deal with those
++    * edge cases yet, we just disable the autotuner for small RPs entirely for now.
++    */
++   if (cmd_buffer->state.rp.drawcall_count < 5)
++      return true;
++
+    /* We use 64bit hash as a key since we don't fear rare hash collision,
+     * the worst that would happen is sysmem being selected when it should
+     * have not, and with 64bit it would be extremely rare.
+-- 
+2.34.1
+