<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I tried to track down that define in git history, but there weren't many clues. That define seems to go all the way back to softpipe (see `#define SP_MAX_VBUF_SIZE 4096` on src/gallium/drivers/softpipe/sp_prim_vbuf.c added on <a href="https://gitlab.freedesktop.org/mesa/mesa/commit/2d37e78e636e5e1e7d5d00230e50a00f7a71e868">https://gitlab.freedesktop.org/mesa/mesa/commit/2d37e78e636e5e1e7d5d00230e50a00f7a71e868</a> .
At that time before softpipe had 64K, i915 had 16K and then softpipe got 4K, which llvmpipe eventually inherited.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I believe it's as Roland said -- probably smaller sizes were empirically shown to be better. I recall that a lot of effort had went on making SW TNL fast around that time, for Intel Poulsbo IIRC (because the GPU was so under-powered that using the CPU for
VS allowed for everything to run faster!) The issue was not just the final vertex buffer size, but also forcing a small batch of vertices through the draw pipeline, which was quite deep, at least then, where every stage of the pipeline would sweep over all
the vertices, and most of the stages were hand written C.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I think that nowadays, at least with llvmpipe, the draw pipeline is less deep, as a lot of what were discrete pipeline stages (e.g, clipping and final emission) are actually compiled in into the JITted VS. So I'd imagine llvmpipe (or anything that uses draw
w/ LLVM) should now be able to sustain much larger batches without trashing the caches.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
IIRC, mesademos' ipers/engine/fire (don't recall exactly which) were the sort of thing people used to fine tune this sort of thing. There are probably better benchmarks nowadays though.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Jose</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Roland Scheidegger <sroland@vmware.com><br>
<b>Sent:</b> Thursday, February 20, 2020 17:27<br>
<b>To:</b> Dave Airlie <airlied@gmail.com>; mesa-dev <mesa-dev@lists.freedesktop.org><br>
<b>Cc:</b> Jose Fonseca <jfonseca@vmware.com><br>
<b>Subject:</b> Re: size of LP_MAX_VBUF_SIZE</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Am 20.02.20 um 02:45 schrieb Dave Airlie:<br>
> Hey,<br>
> <br>
> Anyone know why LP_MAX_VBUF_SIZE is only 4K?<br>
> <br>
> Tess submits > 100K verts to the draw pipeline, which start to split<br>
> them, due to the 4K size of the above it splits 50 vertices per vbuf,<br>
> however it then calls draw_reset_vertex_ids which iterates over all<br>
> 100K vertices each time.<br>
> <br>
> I might try fixing the reset, but I wondered why this was only sending<br>
> 50 vertices at a time to the rasterizer.<br>
> <br>
> Dave.<br>
> <br>
<br>
Dave,<br>
<br>
I don't recall, I think this even predates me working on llvmpipe...<br>
That said, I think in general splitting into smaller chunks is done so<br>
things are more cache friendly (though the limit is so low it would fit<br>
into l1 cache even back then...). And probably the overhead of invoking<br>
things multiple times just wasn't all that large compared to the<br>
execution time of the vs (and the setup code in llvmpipe).<br>
I don't know if that was actually measured though at some point, and it<br>
is quite possible the average vertex size got quite a bit larger since<br>
then (hence max vertices per split lower), as everything was geared<br>
towards quite simple apps back then.<br>
<br>
So I think increasing the limit is probably quite fine, but splitting<br>
still needs to work correctly.<br>
<br>
Roland<br>
</div>
</span></font></div>
</body>
</html>