On Tue, Dec 2, 2014 at 11:20 PM, Ben Widawsky <b...@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.widaw...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev