Waiting for https://gitlab.khronos.org/vulkan/vulkan/-/issues/3131 resolution.
TLDR: it seems that VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT does not expect that tilers may have the value multiplied by tile count, and it doesn't expect that some internal blits may be counted towards it.
For pipeline statistics there is a note:
For example, tile-based rendering devices may need to replay the scene multiple times, affecting some of the counts.
However there is no such note for
VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT. OpenGL spec isn't much clearer either, for
GL_PRIMITIVES_GENERATED it tells:
the primitives-generated count is incremented every time a primitive emitted to that stream reaches the transform feedback stage (see section 13.3), whether or not transform feedback is active. This counter counts the number of primitives emitted by a geometry shader, if active, possibly further tessellated into separate primitives during the transform feedback stage, if active.
When BeginQueryIndexed is called with a target of TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN [...] These two types of queries can be used together to determine if all primitives in a given vertex stream have been written to the bound feedback buffers; if both queries are run simultaneously and the query results are equal, all primitives have been written to the buffer(s). If the number of primitives written is less than the number of primitives generated, one or more buffers overflowed.
So this places a restriction on when
VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT is running alongside XFB +
VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT, in such case they should be equal when there is no overflow.
However what if
VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT runs without XFB, is it allowed to return the same value as
VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT, which on tilers could be multiplied by the number of tiles?
Looking at available GL and VK tests I think that
VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT should not count 3d blits and multiple tiles, but I'd wait for issue resolution.
Also see #6602 (closed)