> -----Original Message----- > From: Emil Velikov [mailto:emil.l.veli...@gmail.com] > Sent: Tuesday, July 25, 2017 11:22 PM > To: Marathe, Yogesh <yogesh.mara...@intel.com> > Cc: Wu, Zhongmin <zhongmin...@intel.com>; ML mesa-dev <mesa- > d...@lists.freedesktop.org>; Kondapally, Kalyan > <kalyan.kondapa...@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 > > 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/c > > mds/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.
Yes, it won't be functional without patch. > > About the performance numbers in question - I hope you've looked at my > comment in 1/2. Yes. I saw that. > > -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
