On 25 July 2017 at 15:30, Marathe, Yogesh <yogesh.mara...@intel.com> wrote: > Emil, > >> -----Original Message----- >> From: Emil Velikov [mailto:emil.l.veli...@gmail.com] >> Sent: Tuesday, July 25, 2017 7:46 PM >> To: Wu, Zhongmin <zhongmin...@intel.com> >> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>; Kondapally, Kalyan >> <kalyan.kondapa...@intel.com>; Marathe, Yogesh >> <yogesh.mara...@intel.com>; Antognolli, Rafael >> <rafael.antogno...@intel.com>; Gao, Shuo <shuo....@intel.com>; Tomasz Figa >> <tf...@chromium.org>; Chris Wilson <ch...@chris-wilson.co.uk>; Eric >> Engestrom <e...@engestrom.ch>; Rob Herring <r...@kernel.org>; Daniel >> Stone <dani...@collabora.com>; Varad Gautam >> <varad.gau...@collabora.com>; Liu, Zhiquan <zhiquan....@intel.com>; Frank >> Binns <frank.bi...@imgtec.com>; Brendan King <brendan.k...@imgtec.com>; >> Martin Peres <martin.pe...@linux.intel.com> >> Subject: Re: [PATCH 2/2] i965: Queue the buffer with a sync fence for Android >> OS v4.2 >> >> Hi Zhongmin, >> >> Thanks you for the update. There's a couple of important comments - >> dri2_make_current + droid_window_enqueue_buffer. >> The rest is just nitpiks. >> >> Tomasz, hats down for the immense help and guidance. >> >> On the potential performance hit (due to the extra fence), I think we could >> do >> some tests before adding extra infra. >> No obvious benchmarks come to mind - any suggestions? >> > > Sorry to jump in, flatland is the one native application on android that > tests this > explicitly. It gives time required to render one frame of particular > resolution without > other services running. It’s a native app that comes with aosp. And we found > this > issue just because of that. > > App info - > https://android.googlesource.com/platform/frameworks/native/+/master/cmds/flatland/README.txt > Bug - https://bugs.freedesktop.org/show_bug.cgi?id=101655 > > I already tested this patch set with android and I can see scores not being > that great. > May be this is the one we can use to profile this or I can continue to > profile based on > guidance here. > I meant a completely different thing:
Don't bother with premature optimisations - see if/how much overhead of the patch itself adds (ideally on most platforms). Aka - test before/after. Which in the case of flatland is not possible, if I understood you correctly. About the performance numbers in question - I hope you've looked at my comment in 1/2. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
