[Mesa-dev] swr: RDTSC StopCapture hangs

[Victor Moya del Barrio]

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.

Victor


On Thu, Sep 8, 2016 at 8:35 PM, Rowley, Timothy O <
timothy.o.rowley at intel.com> wrote:

> 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?
>
> 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.
>
> Thanks.
>
> -Tim
>
> > On Sep 8, 2016, at 6:55 AM, Victor Moya del Barrio <
> victor.moya.del.barrio at gmail.com> wrote:
> >
> >
> > Again playing with OpenSWR running on a (OpenSWR originally intended)
> many core system.
> >
> > When enabling RDTSC Buckets profiling sometimes OpenSWR gets stuck on
> StopCapture.
> >
> > 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.
> >
> > 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.
> >
> > 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).
> >
> > Thread 39 (WORKER)
> >  %Tot   %Par  Cycles     CPE        NumEvent   CPE2       NumEvent2
> Bucket
> >  85.57  85.57 171485899  2243       76423      0          0
> WorkerWorkOnFifoBE
> >  24.45  28.58 49002850   125648     390        0          0          |->
> WorkerFoundWork
> >
> >
> > Victor
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160909/87d5da5c/attachment.html>