[Mesa-dev] Question about min_index/max_index calculation

[Erico Nunes]

Thanks all for the input.

I don't have an in-depth knowledge of the hardware either, though as
far as we can see the hardware does expect that we pass min_index in
the command stream. max_index is used to calculate the sizes in other
command stream fields (which is not the same as pipe_draw_info.count).
The existing lima-ng implementation does the same:
https://github.com/limadriver-ng/lima/blob/660a940c8cc151fd886559233c1a22385ee5f254/limare/lib/gp.c#L584
(draw->vertex_start).

On Sat, Mar 17, 2018 at 7:23 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> For an approximation, you can use the sizes of the bound vbo's to
> guess a min/max index. See
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4/vc4_draw.c#n183
> for an example.

I quickly played with porting something like that to mesa-lima but I
don't think it can solve our problem.
Apparently our bo currently have a fairly large fixed size so I'm not
sure we can do an equivalent calculation using bo size.
And then, min_index is required too.

On Sat, Mar 24, 2018 at 10:32 PM, Marek Olšák <maraeo at gmail.com> wrote:
> Here is how to do it:
>
> if (max_index != ~0u)
>    // index bounds are valid;
> else
>    // scan the index buffer manually;
>
> u_vbuf_get_minmax_index can be used for the scanning.

mesa-lima currently does not use any vbuf function. And we currently
can't call u_vbuf_get_minmax_index since it's static in u_vbuf.c.

I suppose we can consider making u_vbuf_get_minmax_index public then.
I tested this and it works for me. It's still a bit annoying since we
need to create fields probably in lima_context (like
vc4_context.max_index does) and use those instead of the ones in
pipe_draw_info. But not a big problem I guess. We could submit this
refactor when mesa-lima gets proposed upstream.

Just for completeness, one other idea that came up was to define a new
PIPE_CAP_xxx config used to override
st_context.draw_needs_minmax_index, and set that in this driver. This
way, pipe_draw_info would come correctly filled and we wouldn't need
to explicitly assemble minmax indices during the driver draw_vbo. How
does this sound compared to the other solution?