[Mesa-dev] [PATCH] [v2] i965: implement ARB_pipeline_statistics_query

[Ilia Mirkin]

On Tue, Dec 2, 2014 at 11:20 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> On Tue, Dec 02, 2014 at 10:47:37PM -0500, Ilia Mirkin wrote:
>> On Tue, Dec 2, 2014 at 9:33 PM, Ben Widawsky
>> <benjamin.widawsky at intel.com> wrote:
>> > This patch implements ARB_pipeline_statistics_query. This addition to GL does
>> > not add a new API. Instead, it adds new tokens to the existing query APIs. The
>> > work to hook up the new tokens is trivial due to it's similarity to the previous
>> > work done for the query APIs. I've implemented all the new tokens to some
>> > degree, but have stubbed out the untested ones at the entry point for Begin().
>> > Doing this should allow the remainder of the code to be left in.
>> >
>> > The new tokens give GL clients a way to obtain stats about the GL pipeline.
>> > Generally, you get the number of things going in, invocations, and number of
>> > things coming out, primitives, of the various stages. There are two immediate
>> > uses for this, performance information, and debugging various types of
>> > misrendering. I doubt one can use these for debugging very complex applications,
>> > but for piglit tests, it should be quite useful.
>> >
>> > Tessellation shaders, and compute shaders are not addressed in this patch
>> > because there is no upstream implementation. I've implemented how I believe
>> > tessellation shader stats will work for Intel hardware (though there is a bit of
>> > ambiguity). Compute shaders are a bit more interesting though, and I don't yet
>> > know what we'll do there.
>> >
>> > For the lazy, here is a link to the relevant part of the spec:
>> > https://www.opengl.org/registry/specs/ARB/pipeline_statistics_query.txt
>> >
>> > Running the piglit tests
>> > http://lists.freedesktop.org/archives/piglit/2014-November/013321.html
>> > (http://cgit.freedesktop.org/~bwidawsk/piglit/log/?h=pipe_stats)
>> > yield the following results:
>> >
>> >> python2 ./piglit-run.py -t stats tests/all.py output/pipeline_stats
>> >> [5/5] pass: 5 Running Test(s): 5
>> >
>> > Previously I was seeing the adjacent vertex test failing on certain Intel
>> > hardware. I am currently not able to reproduce this, and therefore for now, I'll
>> > assume it was some transient issue which has been fixed.
>> >
>> > v2:
>> > - Don't allow pipeline_stats to be per stream (Ilia). This would be needed for
>> >   AMD_transform_feedback4, which we do not support.
>> >    > If AMD_transform_feedback4 is supported then GEOMETRY_SHADER_PRIMITIVES_-
>> >    > EMITTED_ARB counts primitives emitted to any of the vertex streams for which
>> >    > STREAM_RASTERIZATION_AMD is enabled.
>>
>> Actually it wouldn't be needed even if mesa supported AMD_tf4. The way
>> I'm reading it, the counter should count primitives emitted to *ANY*
>> vertex stream with rasterization, not keep separate counters per
>> vertex stream.
>>
>
> I'll defer to you on this since I really don't understand the implications of
> TF4. I don't quite understand how "any" makes sense when there are multiple
> vertex streams coming from the GS. So, I read it as, you need to capture all and
> let the user of the API figure out what to do with it. Again, I'm more than
> happy to defer to you on that.

Well, I don't want to make it seem like I'm some sort of expert on
this, but I think the deal is that with ARB_tf4, you can rasterize
primitives from multiple streams. The counter is expected to be the
sum of all emitted primitives from any streams that have rasterization
enabled. Imagine that there's a counter at the end of each stream, you
need to return the sum of all those counters. At least that's how I'm
reading it.

  -ilia