[Mesa-dev] [PATCH 02/21] etnaviv: extract get_mystery_meat_load_balancing

Philipp Zabel p.zabel at pengutronix.de
Tue Jun 5 14:38:26 UTC 2018


From: Michael Tretter <m.tretter at pengutronix.de>

Extract the mystery meat load balancing calculation into a function that
can also be called from the NIR compiler implementation.

Signed-off-by: Michael Tretter <m.tretter at pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 .../drivers/etnaviv/etnaviv_compiler.c        | 60 +++++++++++--------
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index bbc61a59fc67..ded5154c6f96 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -248,6 +248,37 @@ sort_rec_compar(const struct sort_rec *a, const struct sort_rec *b)
    return 0;
 }
 
+/* Calculate "mystery meat" load balancing value. This value determines how
+ * work is scheduled between VS and PS in the unified shader architecture.
+ * More precisely, it is determined from the number of VS outputs, as well as
+ * chip-specific vertex output buffer size, vertex cache size, and the number
+ * of shader cores.
+ *
+ * XXX this is a conservative estimate, the "optimal" value is only known for
+ * sure at link time because some outputs may be unused and thus unmapped.
+ * Then again, in the general use case with GLSL the vertex and fragment
+ * shaders are linked already before submitting to Gallium, thus all outputs
+ * are used.
+ */
+static inline uint32_t
+get_mystery_meat_load_balancing(struct etna_compile *c, size_t reg_size)
+{
+   assert(etna_shader_is_stage(c, MESA_SHADER_VERTEX));
+
+   int half_out = (reg_size + 1) / 2;
+   assert(half_out);
+
+   uint32_t b = ((20480 / (c->specs->vertex_output_buffer_size -
+                           2 * half_out * c->specs->vertex_cache_size)) +
+                 9) /
+                10;
+   uint32_t a = (b + 256 / (c->specs->shader_core_count * half_out)) / 2;
+   return VIVS_VS_LOAD_BALANCING_A(MIN2(a, 255)) |
+          VIVS_VS_LOAD_BALANCING_B(MIN2(b, 255)) |
+          VIVS_VS_LOAD_BALANCING_C(0x3f) |
+          VIVS_VS_LOAD_BALANCING_D(0x0f);
+}
+
 /* create an index on a register set based on certain criteria. */
 static int
 sort_registers(struct sort_rec *sorted, struct etna_compile_file *file,
@@ -2196,32 +2227,9 @@ fill_in_vs_outputs(struct etna_shader_variant *sobj, struct etna_compile *c)
    /* build two-level index for linking */
    build_output_index(sobj);
 
-   /* fill in "mystery meat" load balancing value. This value determines how
-    * work is scheduled between VS and PS
-    * in the unified shader architecture. More precisely, it is determined from
-    * the number of VS outputs, as well as chip-specific
-    * vertex output buffer size, vertex cache size, and the number of shader
-    * cores.
-    *
-    * XXX this is a conservative estimate, the "optimal" value is only known for
-    * sure at link time because some
-    * outputs may be unused and thus unmapped. Then again, in the general use
-    * case with GLSL the vertex and fragment
-    * shaders are linked already before submitting to Gallium, thus all outputs
-    * are used.
-    */
-   int half_out = (c->file[TGSI_FILE_OUTPUT].reg_size + 1) / 2;
-   assert(half_out);
-
-   uint32_t b = ((20480 / (c->specs->vertex_output_buffer_size -
-                           2 * half_out * c->specs->vertex_cache_size)) +
-                 9) /
-                10;
-   uint32_t a = (b + 256 / (c->specs->shader_core_count * half_out)) / 2;
-   sobj->vs_load_balancing = VIVS_VS_LOAD_BALANCING_A(MIN2(a, 255)) |
-                             VIVS_VS_LOAD_BALANCING_B(MIN2(b, 255)) |
-                             VIVS_VS_LOAD_BALANCING_C(0x3f) |
-                             VIVS_VS_LOAD_BALANCING_D(0x0f);
+   sobj->vs_load_balancing =
+      get_mystery_meat_load_balancing(c,
+                                      c->file[TGSI_FILE_OUTPUT].reg_size);
 }
 
 static bool
-- 
2.17.1



More information about the mesa-dev mailing list