cancel
Showing results for 
Search instead for 
Did you mean: 

Thread Affinity and CPU0

3dcdemos
Explorer
Hello,

I am currently profiling my Gear Vr native application (multi threaded), and I am stuck on a particular issue about thread affinity.

Using Oculus Remote Monitor, I can witness perfect performances almost all the time, except on some occasions when Tearing happens. The thing is, every time a frame is late, there is one of my thread task being run (for approx 8 ms) on CPU0. Whereas, when the same task is being run on any other core, there is no tearing. (see screenshot attached)

My questions:
- is the CPU0 somewhat reserved by the oculus runtime?
- Is there any way for me to set my thread affinity to exclude CPU0 ? (__NR_sched_setaffinity seems not to work on android)
- are threads affinity managed in some way by the oculus runtime?
- what does VrApi trace "TA=F0/F0/F0/F0,SP=F/F/F/F" means exactly? (the documentation "Basic Performance Stats through Logcat" seems dated on this particular part)

thank you.

117wb5lo3og8.png
4 REPLIES 4

doles
Protege
Hi, your hypothesis is pretty close actually!

We have seen this crop up before. On some OS images the graphics driver included only uses kernel workers on CPU0 with default priority. So occupying that core with significant load can cause GL calls to get delayed. And delayed GL calls can cause tearing when we are doing frontbuffer rendering in TimeWarp.

Typically for apps with only 2 big threads setting them in ovrPerformanceParms is enough and we take care of the platform specific details. But if that is too constraining and you need to set affinity yourself that *should* work as follows....

  int mask = ...;
  syscall( __NR_sched_setaffinity, gettid(), sizeof( mask ), &mask );

...the tricky thing with doing that though is not all SoCs are guaranteed to have the same layout of BIG vs LITTLE cores and not all drivers will behave the same in terms of which its own affinity. So if you can, use ovrPerformanceParms for your heavy threads.

doles
Protege
Oh, also, those TA and SP are affinity masks and scheduler policy hex values for...
TimeWarp, DeviceManager, AppMainThread and AppRenderThread.
...the last two are the thread IDs passed in via ovrPerformanceParms.

3dcdemos
Explorer
Great! thank you for this detailed answer.

yeah, unfortunately 2 threads is not enough for my needs.

I am, for now, targeting specifically the Galaxy S7, would you happen to know if __NR_sched_setaffinity would work and with what mask to exclude CPU0 ?

have a nice day!

doles
Protege
const int mask = 0xFFFE;
...should work for excluding CPU0 for the time being. And on current devices that shouldn't cause any issues but hard to make guarantees for future/unknown hardware.

We will likely change the API to something a bit more flexible sometime soon (already making plans for that), so I would be prepared to change to that when it becomes available. PM me privately, might be good to understand your release schedule to see if hack now and "real" fix later works for you.