[Mesa-dev] [PATCH 2/2] i965: Queue the buffer with a sync fence for Android OS v4.2

[Emil Velikov]

On 25 July 2017 at 15:30, Marathe, Yogesh <yogesh.marathe at intel.com> wrote:
> Emil,
>
>> -----Original Message-----
>> From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>> Sent: Tuesday, July 25, 2017 7:46 PM
>> To: Wu, Zhongmin <zhongmin.wu at intel.com>
>> Cc: ML mesa-dev <mesa-dev at lists.freedesktop.org>; Kondapally, Kalyan
>> <kalyan.kondapally at intel.com>; Marathe, Yogesh
>> <yogesh.marathe at intel.com>; Antognolli, Rafael
>> <rafael.antognolli at intel.com>; Gao, Shuo <shuo.gao at intel.com>; Tomasz Figa
>> <tfiga at chromium.org>; Chris Wilson <chris at chris-wilson.co.uk>; Eric
>> Engestrom <eric at engestrom.ch>; Rob Herring <robh at kernel.org>; Daniel
>> Stone <daniels at collabora.com>; Varad Gautam
>> <varad.gautam at collabora.com>; Liu, Zhiquan <zhiquan.liu at intel.com>; Frank
>> Binns <frank.binns at imgtec.com>; Brendan King <Brendan.King at imgtec.com>;
>> Martin Peres <martin.peres at 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