<div dir="ltr">On 9 September 2013 09:18, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/09/2013 10:20 AM, Paul Berry wrote:<br>
> According to GLSL, the shader may call EndPrimitive() at any point<br>
> during its execution, causing the line or triangle strip currently<br>
> being output to be terminated and a new strip to be begun.<br>
><br>
> This is implemented in gen7 hardware by using one control data bit per<br>
> vertex, to indicate whether EndPrimitive() was called after that<br>
> vertex was emitted.<br>
><br>
> In order to make this work without sacrificing too much efficiency, we<br>
> accumulate 32 control data bits at a time in a GRF.  When we have<br>
> accumulated 32 bits (or when the shader terminates), we output them to<br>
> the appropriate DWORD in the control data header and reset the<br>
> accumulator to 0.<br>
><br>
> We have to take special care to make sure that EndPrimitive() calls<br>
> that occur prior to the first vertex have no effect.<br>
<br>
</div>Does this cover the general case of EndPrimitive without a preceeding<br>
EmitVertex?  Something like:<br>
<br>
     EmitVertex();<br>
     EndPrimitive();<br>
     EndPrimitive();<br>
<br>
And... do we have a test for that? :)<br></blockquote><div><br></div><div>Yes, that should work fine.  What we do in EndPrimitive() is set the appropriate bit in the bitfield, so calling EndPrimitive() again should just redundantly set a bit that's already set.<br>
<br>I don't think we have a test for it.  I'll add that to my list.<br></div></div></div></div>