[Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

Zack Rusin zackr at vmware.com
Tue Jun 10 13:23:25 PDT 2014


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 <zackr at 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
> 


More information about the mesa-dev mailing list