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.row...@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.bar...@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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
