draw: force draw pipeline if there's more than 65535 vertices
authorRoland Scheidegger <sroland@vmware.com>
Sat, 21 Jul 2018 23:05:39 +0000 (01:05 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Mon, 23 Jul 2018 20:07:07 +0000 (22:07 +0200)
commit09828feab0bdcb1feb0865fc66e5304f6164c3b8
tree8b2b89b49314a63813e00f8686be42530fd27749
parent51f67eeb213bb46b57e442c055e986cff839cb5c
draw: force draw pipeline if there's more than 65535 vertices

The pt emit path can only handle 65535 - the number of vertices is
truncated to a ushort, resulting in a too small buffer allocation, which
will crash.

Forcing the pipeline path looks suboptimal, then again this bug is
probably there ever since GS is supported, so it seems it's not
happening often. (Note that the vertex_id in the vertex header is 16
bit too, however this is only used by the draw pipeline, and it denotes
the emit vertex nr, and that uses vbuf code, which will only emit smaller
chunks, so should be fine I think.)
Other solutions would be to simply allow 32bit counts for vertex
allocation, however 65535 is already larger than this was intended for
(the idea being it should be more cache friendly). Or could try to teach
the pt emit path to split the emit in smaller chunks (only the non-index
path can be affected, since gs output is always linear), but it's a bit
tricky (we don't know the primitive boundaries up-front).

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=107295
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/draw/draw_pt_emit.c
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c