<div dir="ltr"><br><div>I'm seeing this behavior when running the refract test ('-b refract') which has a lower framerate than most other tests.  Depending on the start/end frame I select sometimes it gets stuck on that loop in StopCapture and sometime it doesn't (early frames, only one or two frames captured).  I also use to run glmark2 with the '--off-screen --frame-end swap' option.</div><div><br></div><div>Victor</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 8:35 PM, Rowley, Timothy O <span dir="ltr"><<a href="mailto:timothy.o.rowley@intel.com" target="_blank">timothy.o.rowley@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’ve seen the bucket hang on stop in the past, but thought this was now a thing of the past.  Is there a particular workload that was making this easy to trigger?<br>
<br>
What workload of glmark2 were you looking at?  Watching it run, most of the scenes appear very light in geometry, which would cause more contention for work by the BE workers.<br>
<br>
Thanks.<br>
<br>
-Tim<br>
<div><div class="h5"><br>
> On Sep 8, 2016, at 6:55 AM, Victor Moya del Barrio <<a href="mailto:victor.moya.del.barrio@gmail.com">victor.moya.del.barrio@gmail.<wbr>com</a>> wrote:<br>
><br>
><br>
> Again playing with OpenSWR running on a (OpenSWR originally intended) many core system.<br>
><br>
> When enabling RDTSC Buckets profiling sometimes OpenSWR gets stuck on StopCapture.<br>
><br>
> StopCapture waits for all the threads to close all the pending buckets (expects threads to be at bucket level 0) but the problem seems to be that some threads get stuck at WorkerWaitForThreadEvent (level 1) and given that StopCapture is called from SwrEndFrame (in the API thread) they are probably not going to be awaken ever.<br>
><br>
> I don't have a clean solution here because I didn't study with detail how the thread wait/sleep mechanism works (the real problem could be an issue on why some threads are sleeping and other not) so for now I just commented the code in StopCapture that expects all threads to be at level 0.<br>
><br>
> BTW. based on the RDTSC Buckets I see a very horrible utilization of the threads in this system on glmark2.  The BE threads seems to spend most of the cycles on a spin loop looking for work through draw contexts and tiles inside draw contexts, rather than say sleep if there is no real work to be done until there is (but probably there should be as we want higher FPS) (ie the BE thread gets stuck between the WorkerOnFifoBE and WorkerFoundWork buckets).<br>
><br>
> Thread 39 (WORKER)<br>
>  %Tot   %Par  Cycles     CPE        NumEvent   CPE2       NumEvent2  Bucket<br>
>  85.57  85.57 171485899  2243       76423      0          0          WorkerWorkOnFifoBE<br>
>  24.45  28.58 49002850   125648     390        0          0          |-> WorkerFoundWork<br>
><br>
><br>
> Victor<br>
</div></div>> ______________________________<wbr>_________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
<br>
</blockquote></div><br></div>