i965: Implement GL_PRIMITIVES_GENERATED with non-zero streams.
i965: Implement GL_PRIMITIVES_GENERATED with non-zero streams.

So far we have been using CL_INVOCATION_COUNT to resolve this query but this
is no good with streams, as only stream 0 reaches the clipping stage.

From ARB_transform_feedback3:

"When a generated primitive query for a vertex stream is active, the
 primitives-generated count is incremented every time a primitive emitted to
 that stream reaches the Discarding Rasterization stage (see Section 3.x)
 right before rasterization. This counter is incremented whether or not
 transform feedback is active."

Unfortunately, we don't have any registers that provide the number of primitives
written to a specific stream other than the ones that track the number of
primitives written to transform feedback in the SOL stage, so we can't
implement this exactly as specified.

In the past we implemented this feature by activating the SOL unit even if
transform feeback was disabled, but making it so that all buffers were
disabled and it only recorded statistics, which gave us the right semantics
(see 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5). Unfortunately, this came with
a significant performance impact and had to be reverted.

This new take does not intend to implement the exact semantics required by
the spec, but improves what we have now, since now we return the primitive
count for stream 0 in all cases. With this patch we use
GEN7_SO_PRIM_STORAGE_NEEDED to resolve GL_PRIMITIVES_GENERATED queries
for non-zero streams. This would return the number of primitives written
to transform feedback for each stream instead. Since non-zero streams are
only useful in combination with transform feedback this should not be too
bad, and the only case that I think we would not be supporting would be
the one in which we want to use both GL_PRIMITIVES_GENERATED and
GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN on the same non-zero stream to
detect buffer overflow.

This patch also fixes the following piglit test:
arb_gpu_shader5-xfb-streams-without-invocations

This test uses both GL_PRIMITIVES_GENERATED and
GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries on non-zero streams, but it
does never hit the overflow case, so both queries are always expected to return
the same value.

Reviewed-by: Kenneth Graunke <bd2562f754ec92342f93f61c25d731e290a2ffa8@whitecape.org>
Cc: "10.3" <59f39c0db42d4479a46b02d4d2bc11120e37bb44@lists.freedesktop.org>

metora/MesaGLSLCompiler,djreep81/glsl-optimizer,djreep81/glsl-optimizer,jbarczak/glsl-optimizer,zeux/glsl-optimizer,benaadams/glsl-optimizer,bkaradzic/glsl-optimizer,benaadams/glsl-optimizer,jbarczak/glsl-optimizer,wolf96/glsl-optimizer,zeux/glsl-optimizer,tokyovigilante/glsl-optimizer,metora/MesaGLSLCompiler,mcanthony/glsl-optimizer,djreep81/glsl-optimizer,mcanthony/glsl-optimizer,dellis1972/glsl-optimizer,dellis1972/glsl-optimizer,wolf96/glsl-optimizer,benaadams/glsl-optimizer,wolf96/glsl-optimizer,zeux/glsl-optimizer,bkaradzic/glsl-optimizer,benaadams/glsl-optimizer,tokyovigilante/glsl-optimizer,zz85/glsl-optimizer,bkaradzic/glsl-optimizer,zz85/glsl-optimizer,zeux/glsl-optimizer,dellis1972/glsl-optimizer,tokyovigilante/glsl-optimizer,zeux/glsl-optimizer,djreep81/glsl-optimizer,benaadams/glsl-optimizer,jbarczak/glsl-optimizer,benaadams/glsl-optimizer,tokyovigilante/glsl-optimizer,mcanthony/glsl-optimizer,wolf96/glsl-optimizer,dellis1972/glsl-optimizer,zz85/glsl-optimizer,dellis1972/glsl-optimizer,bkaradzic/glsl-optimizer,zz85/glsl-optimizer,mcanthony/glsl-optimizer,jbarczak/glsl-optimizer,metora/MesaGLSLCompiler,zz85/glsl-optimizer,djreep81/glsl-optimizer,bkaradzic/glsl-optimizer,wolf96/glsl-optimizer,jbarczak/glsl-optimizer,tokyovigilante/glsl-optimizer,mcanthony/glsl-optimizer,zz85/glsl-optimizer