From f16312c01b825b723b25da8ea895ceca01a97484 Mon Sep 17 00:00:00 2001 From: Boris Brezillon Date: Tue, 14 Nov 2023 13:53:49 +0100 Subject: [PATCH] panfrost: Express the per-batch limit in term of draws We turn the 10000 jobs limit into a 10000 draw limit because: - on HW supporting IDVS a draw is just a single job, and having a common limit for all HW is simpler - draw_count < 10000 fits in the max jobs limit if we assume the worst case scenario (3 jobs per draw) - CI seems to be happy (no spurious timeouts after this change) Signed-off-by: Boris Brezillon Reviewed-by: Erik Faye-Lund Part-of: --- src/gallium/drivers/panfrost/pan_cmdstream.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_cmdstream.c b/src/gallium/drivers/panfrost/pan_cmdstream.c index bc1843e56a3..5b334131f57 100644 --- a/src/gallium/drivers/panfrost/pan_cmdstream.c +++ b/src/gallium/drivers/panfrost/pan_cmdstream.c @@ -3751,10 +3751,13 @@ panfrost_draw_vbo(struct pipe_context *pipe, const struct pipe_draw_info *info, /* Do some common setup */ struct panfrost_batch *batch = panfrost_get_batch_for_fbo(ctx); - /* Don't add too many jobs to a single batch. Hardware has a hard limit - * of 65536 jobs, but we choose a smaller soft limit (arbitrary) to - * avoid the risk of timeouts. This might not be a good idea. */ - if (unlikely(batch->scoreboard.job_index > 10000)) + /* Don't add too many jobs to a single batch. Job manager hardware has a + * hard limit of 65536 jobs per job chain. Given a draw issues a maximum + * of 3 jobs (a vertex, a tiler and a compute job is XFB is enabled), we + * could use 65536 / 3 as a limit, but we choose a smaller soft limit + * (arbitrary) to avoid the risk of timeouts. This might not be a good + * idea. */ + if (unlikely(batch->draw_count > 10000)) batch = panfrost_get_fresh_batch_for_fbo(ctx, "Too many draws"); bool points = (info->mode == MESA_PRIM_POINTS);