I think the code is already correct and something else goes wrong. The tgsi geometry shader code was never done properly so it's more than likely that tgsi_exec is doing something wonky.
Geometry shaders specify the maximum number of vertices that they can emit. That's what draw_geometry_shader::max_output_vertices is. If a geometry shader emits more than that, the verts will be ignored. So our primitive_boundary is max_output_vertices + 1 because we want to make sure that in SoA we have a scratch space where we can keep writing the overflowed vertices. So the worst case scenario for our output buffer is: (max_output_vertices + 1) * geometry shader invocations. That's what we have there now and that's correct. I don't remember what tgsi_exec does, I think I never even implemented proper SoA for gs in tgsi_exec, so if there's anything wrong I'd look for the bug there. z ----- Original Message ----- > On 11 June 2014 00:02, Zack Rusin <za...@vmware.com> wrote: > > That looks wrong. The total number of verts per buffer is the maximum > > number of verts that can be output per invocation (primitive_boundary) > > times number of invocations of geometry shader (num_in_primitives). > > > > It's not maximum number of verts that can be output per invocation > > (primitive_boundary) times maximum number of primitives output by geometry > > shader (max_out_prims). > > > > Okay so just adding * u_vertices_per_prim(shader->output_primitive); > would suffice? > > Dave > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
