You're right, that's a bad idea and doesn't work.
On Fri, Jun 27, 2014 at 6:09 PM, Iago Toral wrote:
> If by not doing anything you mean not processing or removing the
> ir_emit_vertex instructions for that stream this would have two problems
> at least:
>
> 1) We won't get correct results for GL
If by not doing anything you mean not processing or removing the
ir_emit_vertex instructions for that stream this would have two problems
at least:
1) We won't get correct results for GL_PRIMITIVES_GENERATED in that
stream (it will always be 0). This may be a minor problem.
2) If that stream is s
As an alternative -- we know if we have this scenario at link time --
could we perhaps just not do anything in EmitStreamVertex if there are
no varyings captured to that stream?
On Thu, Jun 26, 2014 at 10:26 PM, Iago Toral wrote:
> Hello,
>
> while testing various scenarios for multi-stream suppo
Hello,
while testing various scenarios for multi-stream support in geometry
shaders I came across one that I think might be a hardware bug, or at
the very least, a hardware limitation that creates a problem to
implement correct behavior according to ARB_transform_feedback3.
The conflictive scenar