[Bug 84104] Ring hang with geometry shaders on SNB

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84104

--- Comment #4 from Iago Toral <itoral at igalia.com> ---
(In reply to comment #3)
> (In reply to comment #1)
> > Our use of "Dual OWord Block" messages appears to be confusing the
> > simulator; the second offset is not set to a proper value, so it usually
> > ends up being out-of-range and tripping assertions.  We may want to use a
> > different kind of message.
> 
> Right. For the record, the docs say that the hardware checks for
> out-of-range writes and does not execute them.
> 
> > But, that doesn't appear to be the real problem.  Tentatively, it looks like
> > the clipper is hitting an assertion about an unknown primitive topology
> > exiting the GS.
> 
> mmm... that's interesting.
> 
> > On Gen6, it appears that we have to set the output topology in the GS URB
> > Write message header.  I am not convinced that we're doing that correctly in
> > all cases.  I noticed we zero out the input topology field in g0 right away
> > - which should be fine, because we have the output topology as
> > prog_data->output_topology.  We attempt to set that properly, but I'm not
> > sure if we set it on every vertex - it looks like we may only set it on the
> > first one.  Perhaps someone can sanity check this.
> 
> Sure, let me have a look and I'll update here.

Fore reference, the geometry shader used by this test is this:

#version 150
layout(triangles_adjacency) in;
layout(points, max_vertices = 1) out;
out int primitive_id;
void main()
{
  primitive_id = gl_PrimitiveIDIn;
  EmitVertex();
}


Since this particular test has an output type of points, we just set
_3DPRIM_POINTLIST directly on every vertex we see. We always set the output
topology type on every vertex anyway, whether the output is points or not:

gen6_gs_visitor::visit(ir_emit_vertex *)
{
(...)
   if (c->gp->program.OutputType == GL_POINTS) {
      /* If we are outputting points, then every vertex has PrimStart and
       * PrimEnd set.
       */
      emit(MOV(dst, (_3DPRIM_POINTLIST << URB_WRITE_PRIM_TYPE_SHIFT) |
               URB_WRITE_PRIM_START | URB_WRITE_PRIM_END));
      emit(ADD(dst_reg(this->prim_count), this->prim_count, 1u));
   } else {
      /* Otherwise, we can only set the PrimStart flag, which we have stored
       * in the first_vertex register. We will have to wait until we execute
       * EndPrimitive() or we end the thread to set the PrimEnd flag on a
       * vertex.
       */
      emit(OR(dst, this->first_vertex,
              (c->prog_data.output_topology << URB_WRITE_PRIM_TYPE_SHIFT)));
      emit(MOV(dst_reg(this->first_vertex), 0u));
   }
(...)
}

The comment in the else branch refers to another flag that we only need to set
for the last vertex in a primitive, but as you can see, the output topology
type is always set.

> > That said, I'm also seeing utterly bizarre values for topology in the
> > simulator dump output - in the "primitive-id-restart
> > GL_TRIANGLE_STRIP_ADJACENCY" test, it sure looks like we're getting
> > 3DPRIM_QUADSTRIP going from the VS->GS, and again going from GS->CL (which
> > is unsupported, and will trigger an assert).
> >
> > Maybe my analysis is wrong; I can't imagine how that could be.

In this particular example with points output, 3DPRIM_QUADSTRIP In the GS->CL
stage can't happen, since for an output type of points we just write
_3DPRIM_POINTLIST as I explain above. That said, it is interesting that you
also see 3DPRIM_QUADSTRIP going from the VS to the GS. I'll debug the output of
the VS and update here if I see something interesting.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140922/a0f50ec7/attachment.html>