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 <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26249>

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);