<div dir="ltr"><div>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.<br><br></div><div>If you rely on u_vbuf to upload vertices for you, you shouldn't need the index bounds.<br></div><div><br></div>Marek<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes <span dir="ltr"><<a href="mailto:nunes.erico@gmail.com" target="_blank">nunes.erico@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I have been working to add indexed drawing/glDrawElements support to<br>
the mesa-lima driver currently in development<br>
(<a href="https://github.com/yuq/mesa-lima" rel="noreferrer" target="_blank">https://github.com/yuq/mesa-l<wbr>ima</a>).<br>
For that implementation, it seems that we need to have the minimum and<br>
maximum index values from the index buffer available in order to set<br>
up a proper command stream.<br>
Mesa provides these values in pipe_draw_info.min_index and<br>
pipe_draw_info.max_index, however in some cases we noticed that it<br>
decides to not calculate those. This happens because of<br>
st_context.draw_needs_minmax_i<wbr>ndex being false after evaluating the<br>
vertex data. In those cases, min_index gets to be 0 and max_index gets<br>
to be 0xffffffff.<br>
According to the gallium documentation, this seems to be on purpose<br>
and apparently drivers should be able to handle the 0 and 0xffffffff<br>
case and be able to render anyway. However, we haven't figured out a<br>
way to do the render anyway with 0 and 0xffffffff.<br>
<br>
For us it would be interesting to always have mesa calculate those<br>
values for indexed drawing. We haven't been able to figure out a way<br>
to do that without changing the mesa generic code. Is there some way<br>
we could accomplish that in driver specific code?<br>
Otherwise, can you provide some advice on how to best handle this?<br>
<br>
Using mesa 17.3 and kmscube with the following patch is one way to<br>
reproduce st_context.draw_needs_minmax_i<wbr>ndex not being set.<br>
<a href="https://gist.githubusercontent.com/enunes/366398fbee3d194deb3a46ef9c2ca78d/raw/82a2c8084236e35635b7a247609213d0068974e3/kmscube.patch" rel="noreferrer" target="_blank">https://gist.githubusercontent<wbr>.com/enunes/366398fbee3d194deb<wbr>3a46ef9c2ca78d/raw/82a2c808423<wbr>6e35635b7a247609213d0068974e3/<wbr>kmscube.patch</a><br>
The only way that this works for us with the current implementation is<br>
by hacking st_context.draw_needs_minmax_i<wbr>ndex to be always true in<br>
some way.<br>
<br>
Thanks<br>
<br>
Erico<br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</blockquote></div><br></div></div>