On 6 December 2011 23:54, Kenneth Graunke <span dir="ltr">&lt;<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; +   if (intel-&gt;gen == 6) {<br><div><div class="h5">
&gt; +      /* On Gen6, GS is used for transform feedback. */<br>
&gt; +      key-&gt;need_gs_prog = ctx-&gt;TransformFeedback.CurrentObject-&gt;Active;<br>
&gt; +   } else if (intel-&gt;gen &gt;= 7) {<br>
&gt; +      /* On Gen7 and later, we don&#39;t use GS (yet). */<br>
&gt; +      key-&gt;need_gs_prog = false;<br>
<br>
</div></div>Could you please put these in order?  6, 7+, 4-5 is just asking for OCD<br>
issues. :)  I&#39;d probably move the &gt;= 7 check to the top.<br></blockquote><div><br>Oh, whoops.  Normally I am sufficiently OCD to notice stuff like this.  I must be cured!<br><br>I assume when you say &quot;I&#39;d probably move the &gt;= 7 check to the top&quot; you mean that the order you&#39;d prefer is 7+, then 6, then 4-5.  That works for me--it&#39;s nice to have the most recent stuff first.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">&gt; diff --git a/src/mesa/drivers/dri/i965/gen6_gs_state.c b/src/mesa/drivers/dri/i965/gen6_gs_state.c<br>
&gt; index d29f029..b041140 100644<br>
&gt; --- a/src/mesa/drivers/dri/i965/gen6_gs_state.c<br>
&gt; +++ b/src/mesa/drivers/dri/i965/gen6_gs_state.c<br>
&gt; @@ -44,22 +44,36 @@ upload_gs_state(struct brw_context *brw)<br>
&gt;     OUT_BATCH(0);<br>
&gt;     ADVANCE_BATCH();<br>
&gt;<br>
&gt; -   // GS should never be used on Gen6.  Disable it.<br>
&gt; -   assert(!brw-&gt;gs.prog_active);<br>
&gt; -   BEGIN_BATCH(7);<br>
&gt; -   OUT_BATCH(_3DSTATE_GS &lt;&lt; 16 | (7 - 2));<br>
&gt; -   OUT_BATCH(0); /* prog_bo */<br>
&gt; -   OUT_BATCH((0 &lt;&lt; GEN6_GS_SAMPLER_COUNT_SHIFT) |<br>
&gt; -          (0 &lt;&lt; GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));<br>
&gt; -   OUT_BATCH(0); /* scratch space base offset */<br>
&gt; -   OUT_BATCH((1 &lt;&lt; GEN6_GS_DISPATCH_START_GRF_SHIFT) |<br>
&gt; -          (0 &lt;&lt; GEN6_GS_URB_READ_LENGTH_SHIFT) |<br>
&gt; -          (0 &lt;&lt; GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));<br>
&gt; -   OUT_BATCH((0 &lt;&lt; GEN6_GS_MAX_THREADS_SHIFT) |<br>
&gt; -          GEN6_GS_STATISTICS_ENABLE |<br>
&gt; -          GEN6_GS_RENDERING_ENABLE);<br>
&gt; -   OUT_BATCH(0);<br>
&gt; -   ADVANCE_BATCH();<br>
&gt; +   if (brw-&gt;gs.prog_active) {<br>
&gt; +      BEGIN_BATCH(7);<br>
&gt; +      OUT_BATCH(_3DSTATE_GS &lt;&lt; 16 | (7 - 2));<br>
&gt; +      OUT_BATCH(brw-&gt;gs.prog_offset);<br>
&gt; +      OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE);<br>
&gt; +      OUT_BATCH(0); /* no scratch space */<br>
&gt; +      OUT_BATCH((1 &lt;&lt; GEN6_GS_DISPATCH_START_GRF_SHIFT) |<br>
&gt; +             (brw-&gt;gs.prog_data-&gt;urb_read_length &lt;&lt; GEN6_GS_URB_READ_LENGTH_SHIFT));<br>
&gt; +      OUT_BATCH(((brw-&gt;max_gs_threads - 1) &lt;&lt; GEN6_GS_MAX_THREADS_SHIFT) |<br>
&gt; +             GEN6_GS_STATISTICS_ENABLE |<br>
&gt; +             GEN6_GS_SO_STATISTICS_ENABLE |<br>
&gt; +             0); //GEN6_GS_RENDERING_ENABLE);<br>
<br>
</div></div>I&#39;m rather surprised this works.  I thought you needed the<br>
GEN6_GS_RENDERING_ENABLE bit set in order to draw anything at all.<br>
<br>
The commented out code looks like it came from a half-baked patch of<br>
mine, so I&#39;m guessing it&#39;s unintentional.  Still, do you have any idea<br>
why it would work?<br></blockquote><div><br>Whoops.  You&#39;re right of course.  My best guess for why it worked is that when the GS is enabled, this bit doesn&#39;t have much effect--it just gets passed on to the GS program, which is supposed to use it to decide whether to pass vertices down the pipeline.  Since I haven&#39;t written the part of the GS program that disables rendering yet, the GS program was just ignoring the incorrect bit and sending the vertices anyway.<br>
<br>Still, it&#39;s asking for trouble to set this bit incorrectly--the PRM clearly states &quot;This bit must be set if the thread will attempt to allocate a handle. If clear, the GS thread must not allocate handles (e.g., when only performing stream output without concurrent rendering).&quot;  It&#39;s probably sheer luck that I didn&#39;t crash the GPU.  I&#39;ll fix it.<br>
</div></div>