Re: [Mesa-dev] Question about min_index/max_index calculation

[Marek Olšák]

On Mon, Mar 26, 2018 at 6:39 PM, Erico Nunes  wrote:

> 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/660a940c8cc151fd886559233c1a22
> 385ee5f254/limare/lib/gp.c#L584
> (draw->vertex_start).
>
> On Sat, Mar 17, 2018 at 7:23 PM, Ilia Mirkin  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  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?
>

The PIPE_CAP solution sounds OK.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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  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  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?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Connor Abbott]

On Sat, Mar 24, 2018 at 6:00 PM, Jason Ekstrand  wrote:
> On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák  wrote:
>>
>> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott 
>> wrote:
>>>
>>> If Gallium was being lazy and not
>>> specifying the bounds for internal shaders, that needs to be fixed for
>>> the HW to work properly.
>>
>>
>> I don't understand the sentence. Shaders don't interact with vertex
>> indices. I also don't like the word "lazy". The proper expression is "saving
>> time".
>
>
> I figured he meant for things like u_blitter.  But why those things would be
> using an index buffer is beyond me...

Yeah, that was just speculation. I just meant to explain why Mali
might require the min/max index up-front, unlike other HW (AFAIK). I'm
certainly no expert when it comes to Gallium, and I don't have the
hardware to reproduce the problem.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Jason Ekstrand]

On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák  wrote:

> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott 
> wrote:
>
>> If Gallium was being lazy and not
>> specifying the bounds for internal shaders, that needs to be fixed for
>> the HW to work properly.
>>
>
> I don't understand the sentence. Shaders don't interact with vertex
> indices. I also don't like the word "lazy". The proper expression is
> "saving time".
>

I figured he meant for things like u_blitter.  But why those things would
be using an index buffer is beyond me...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Marek Olšák]

On Sat, Mar 24, 2018 at 5:27 PM, Marek Olšák  wrote:

> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott 
> wrote:
>
>> If Gallium was being lazy and not
>> specifying the bounds for internal shaders, that needs to be fixed for
>> the HW to work properly.
>>
>
> I don't understand the sentence. Shaders don't interact with vertex
> indices. I also don't like the word "lazy". The proper expression is
> "saving time".
>

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.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Marek Olšák]

On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott  wrote:

> If Gallium was being lazy and not
> specifying the bounds for internal shaders, that needs to be fixed for
> the HW to work properly.
>

I don't understand the sentence. Shaders don't interact with vertex
indices. I also don't like the word "lazy". The proper expression is
"saving time".

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Connor Abbott]

My understanding is that unlike most other architectures, Mali does
vertex shading on every vertex up-front, completely ignoring the index
buffer. Primitive assembly and tile binning happen after every vertex
is transformed. There is no cache of transformed vertices. Utgard also
only supports GLES2, so the index buffer data is always passed through
a CPU pointer. Since it's possible to calculate the bounds on the CPU
without stalling, and since the HW was designed with low transistor
count in mind, they don't compute the bounds on the HW, and instead
expect you to pass it through. If Gallium was being lazy and not
specifying the bounds for internal shaders, that needs to be fixed for
the HW to work properly. Or, we need to guess by looking at the vertex
buffer size as Ilia mentioned.

On Sun, Mar 18, 2018 at 12:59 AM, Marek Olšák  wrote:
> The index bounds are computed only when they are needed for uploading
> vertices that are passed via a CPU pointer (user_buffer). In all other
> cases, computing the index bounds has a performance cost, which can be very
> significant.
>
> If you rely on u_vbuf to upload vertices for you, you shouldn't need the
> index bounds.
>
> Marek
>
> On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes  wrote:
>>
>> Hi all,
>>
>> I have been working to add indexed drawing/glDrawElements support to
>> the mesa-lima driver currently in development
>> (https://github.com/yuq/mesa-lima).
>> For that implementation, it seems that we need to have the minimum and
>> maximum index values from the index buffer available in order to set
>> up a proper command stream.
>> Mesa provides these values in pipe_draw_info.min_index and
>> pipe_draw_info.max_index, however in some cases we noticed that it
>> decides to not calculate those. This happens because of
>> st_context.draw_needs_minmax_index being false after evaluating the
>> vertex data. In those cases, min_index gets to be 0 and max_index gets
>> to be 0x.
>> According to the gallium documentation, this seems to be on purpose
>> and apparently drivers should be able to handle the 0 and 0x
>> case and be able to render anyway. However, we haven't figured out a
>> way to do the render anyway with 0 and 0x.
>>
>> For us it would be interesting to always have mesa calculate those
>> values for indexed drawing. We haven't been able to figure out a way
>> to do that without changing the mesa generic code. Is there some way
>> we could accomplish that in driver specific code?
>> Otherwise, can you provide some advice on how to best handle this?
>>
>> Using mesa 17.3 and kmscube with the following patch is one way to
>> reproduce st_context.draw_needs_minmax_index not being set.
>>
>> https://gist.githubusercontent.com/enunes/366398fbee3d194deb3a46ef9c2ca78d/raw/82a2c8084236e35635b7a247609213d0068974e3/kmscube.patch
>> The only way that this works for us with the current implementation is
>> by hacking st_context.draw_needs_minmax_index to be always true in
>> some way.
>>
>> Thanks
>>
>> Erico
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Marek Olšák]

The index bounds are computed only when they are needed for uploading
vertices that are passed via a CPU pointer (user_buffer). In all other
cases, computing the index bounds has a performance cost, which can be very
significant.

If you rely on u_vbuf to upload vertices for you, you shouldn't need the
index bounds.

Marek

On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes  wrote:

> Hi all,
>
> I have been working to add indexed drawing/glDrawElements support to
> the mesa-lima driver currently in development
> (https://github.com/yuq/mesa-lima).
> For that implementation, it seems that we need to have the minimum and
> maximum index values from the index buffer available in order to set
> up a proper command stream.
> Mesa provides these values in pipe_draw_info.min_index and
> pipe_draw_info.max_index, however in some cases we noticed that it
> decides to not calculate those. This happens because of
> st_context.draw_needs_minmax_index being false after evaluating the
> vertex data. In those cases, min_index gets to be 0 and max_index gets
> to be 0x.
> According to the gallium documentation, this seems to be on purpose
> and apparently drivers should be able to handle the 0 and 0x
> case and be able to render anyway. However, we haven't figured out a
> way to do the render anyway with 0 and 0x.
>
> For us it would be interesting to always have mesa calculate those
> values for indexed drawing. We haven't been able to figure out a way
> to do that without changing the mesa generic code. Is there some way
> we could accomplish that in driver specific code?
> Otherwise, can you provide some advice on how to best handle this?
>
> Using mesa 17.3 and kmscube with the following patch is one way to
> reproduce st_context.draw_needs_minmax_index not being set.
> https://gist.githubusercontent.com/enunes/366398fbee3d194deb
> 3a46ef9c2ca78d/raw/82a2c8084236e35635b7a247609213d0068974e3/kmscube.patch
> The only way that this works for us with the current implementation is
> by hacking st_context.draw_needs_minmax_index to be always true in
> some way.
>
> Thanks
>
> Erico
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Question about min_index/max_index calculation

[Ilia Mirkin]

On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes  wrote:
> Hi all,
>
> I have been working to add indexed drawing/glDrawElements support to
> the mesa-lima driver currently in development
> (https://github.com/yuq/mesa-lima).
> For that implementation, it seems that we need to have the minimum and
> maximum index values from the index buffer available in order to set
> up a proper command stream.
> Mesa provides these values in pipe_draw_info.min_index and
> pipe_draw_info.max_index, however in some cases we noticed that it

Do you truly need these? Or would approximate values do?

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.

You can also scan through the index buffer yourself, although it's
obviously slow. There are helpers like u_vbuf_get_minmax_index (esp if
you're using the u_vbuf module). I don't know of any hardware that
really needs these to be exact though.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev