<div dir="ltr">On 30 November 2013 13:14, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.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 11/30/2013 10:29 AM, Paul Berry wrote:<br>
> On 12 November 2013 17:51, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>> wrote:<br>
><br>
>     Signed-off-by: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a><br>
</div>>     <mailto:<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>>><br>
<div><div class="h5">>     ---<br>
>      src/mesa/drivers/dri/i965/brw_vec4_gs.c | 6 ++++++<br>
>      1 file changed, 6 insertions(+)<br>
><br>
>     diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c<br>
>     b/src/mesa/drivers/dri/i965/brw_vec4_gs.c<br>
>     index b52d646..e802c1e 100644<br>
>     --- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c<br>
>     +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c<br>
>     @@ -194,6 +194,12 @@ do_gs_prog(struct brw_context *brw,<br>
>            c.prog_data.output_vertex_size_hwords * 32 *<br>
>     gp->program.VerticesOut;<br>
>         output_size_bytes += 32 *<br>
>     c.prog_data.control_data_header_size_hwords;<br>
><br>
>     +   /* Broadwell stores "Vertex Count" as a full 8 DWord (32 byte)<br>
>     URB output,<br>
>     +    * which comes before the conttrol header.<br>
>     +    */<br>
>     +   if (brw->gen >= 8)<br>
>     +      output_size_bytes += 32;<br>
>     +<br>
>         assert(output_size_bytes >= 1);<br>
>         if (output_size_bytes > GEN7_MAX_GS_URB_ENTRY_SIZE_BYTES)<br>
>            return false;<br>
>     --<br>
>     1.8.3.2<br>
><br>
><br>
> It looks like changes also need to be made to<br>
> vec4_gs_visitor::emit_urb_write_opcode() and<br>
> vec4_gs_visitor::emit_control_data_bits() to offset the vertex data and<br>
> control data by 32 bytes, and to vec4_gs_visitor::emit_thread_end() to<br>
> cause the appropriate data to be written to the vertex count.  Are those<br>
> changes elsewhere in the series?<br>
<br>
</div></div>I handled that in the gen8_vec4_generator class (introduced in patch 12):<br>
<br>
The generate_urb_write() function reserves space:<br>
<br>
void<br>
gen8_vec4_generator::generate_urb_write(vec4_instruction *ir, bool vs)<br>
{<br>
   ...<br>
<br>
   int global_offset = ir->offset;<br>
   /* The GS needs to increment Global Offset by 1 to make room for the extra<br>
    * "Vertex Count" payload at the beginning.<br>
    */<br>
   if (!vs)<br>
      ++global_offset;<br>
<br>
   ...<br>
}<br>
<br>
and generate_gs_thread_end() does a SEND with EOT that writes Vertex Count<br>
at offset 0.<br>
<br>
It seems to work pretty well.  Sorry for the awkward split in the patch series.<br>
<br>
--Ken<br>
</blockquote></div><br></div><div class="gmail_extra">Oh, I see.  I have to admit I'm really not a fan of this approach.  I worry that future maintainers are going to make the same assumption that I made (that the offset used by vec4_gs_visitor is the actual offset that's going to be used by the generated instruction), and they're going to get really confused.  It seems to me that it's not very much more effort to just use the correct offset in vec4_gs_visitor in the first place.<br>
</div></div>