<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Ring hang with geometry shaders on SNB" href="https://bugs.freedesktop.org/show_bug.cgi?id=84104#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Ring hang with geometry shaders on SNB" href="https://bugs.freedesktop.org/show_bug.cgi?id=84104">bug 84104</a> from <a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to <a href="show_bug.cgi?id=84104#c3">comment #3</a>) > (In reply to <a href="show_bug.cgi?id=84104#c1">comment #1</a>) > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>