<div dir="ltr"><br><div>Again playing with OpenSWR running on a (OpenSWR originally intended) many core system.</div><div><br></div><div>When enabling RDTSC Buckets profiling sometimes OpenSWR gets stuck on StopCapture.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div><div>Thread 39 (WORKER)</div><div> %Tot   %Par  Cycles     CPE        NumEvent   CPE2       NumEvent2  Bucket</div><div> 85.57  85.57 171485899  2243       76423      0          0          WorkerWorkOnFifoBE</div><div> 24.45  28.58 49002850   125648     390        0          0          |-> WorkerFoundWork</div></div><div><br></div><div><br></div><div>Victor</div></div>