> -----Original Message----- > From: Emil Velikov [mailto:[email protected]] > Sent: Tuesday, July 25, 2017 11:22 PM > To: Marathe, Yogesh <[email protected]> > Cc: Wu, Zhongmin <[email protected]>; ML mesa-dev <mesa- > [email protected]>; Kondapally, Kalyan > <[email protected]>; Antognolli, Rafael > <[email protected]>; Gao, Shuo <[email protected]>; Tomasz Figa > <[email protected]>; Chris Wilson <[email protected]>; Eric > Engestrom <[email protected]>; Rob Herring <[email protected]>; Daniel > Stone <[email protected]>; Varad Gautam > <[email protected]>; Liu, Zhiquan <[email protected]>; Frank > Binns <[email protected]>; Brendan King <[email protected]>; > Martin Peres <[email protected]> > 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 <[email protected]> > wrote: > > Emil, > > > >> -----Original Message----- > >> From: Emil Velikov [mailto:[email protected]] > >> Sent: Tuesday, July 25, 2017 7:46 PM > >> To: Wu, Zhongmin <[email protected]> > >> Cc: ML mesa-dev <[email protected]>; Kondapally, Kalyan > >> <[email protected]>; Marathe, Yogesh > >> <[email protected]>; Antognolli, Rafael > >> <[email protected]>; Gao, Shuo <[email protected]>; Tomasz > >> Figa <[email protected]>; Chris Wilson <[email protected]>; > >> Eric Engestrom <[email protected]>; Rob Herring <[email protected]>; > >> Daniel Stone <[email protected]>; Varad Gautam > >> <[email protected]>; Liu, Zhiquan <[email protected]>; > >> Frank Binns <[email protected]>; Brendan King > >> <[email protected]>; Martin Peres > >> <[email protected]> > >> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
