[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 <maraeo at gmail.com> 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 <nunes.erico at gmail.com> 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 0xffffffff.
>> According to the gallium documentation, this seems to be on purpose
>> and apparently drivers should be able to handle the 0 and 0xffffffff
>> case and be able to render anyway. However, we haven't figured out a
>> way to do the render anyway with 0 and 0xffffffff.
>>
>> 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>