[Mesa-dev] [EGL android: accquire fence implementation] i965: Queue the buffer with a sync fence for Android OS

[Emil Velikov]

On 11 July 2017 at 16:23, Tomasz Figa <tfiga at chromium.org> wrote:
> Hi Zhongmin,
>
> On Tue, Jul 11, 2017 at 11:02 AM, Wu, Zhongmin <zhongmin.wu at intel.com> wrote:
>> By the way,
>>
>> For cancelBuffer, sorry I forget such function, thanks for notice. It should also pass the same fence fd as the queuebuffer.
>>
>> And Yogesh, you mentioned the gallium,   is it another platform supported by mesa ?  I am sorry I have no idea about this,  could you please help to check this ?
>>
>> I think we can co-work with mesa team to work out an acceptable fix which can meet the requirement of Android without any break on other platforms.
>
> One thing needs clarifying here. Release fences from EGL are _not_ a
> requirement. It is an optional feature. Android compliance suites pass
> fully without Android sync fence support in Mesa at all.
>
> Other than that, it's been taking long enough and I agree that we
> should finally wire both acquire and release fence support in EGL and
> related drivers. Otherwise we can forget about getting good user
> experience on Android.
>
Right, I'm not trying to say otherwise.

The strange part, IMHO, is that now flatland has a hard requirement on
both fences, where the [developer-side of the] documentation does not
say anything about this.
This sounds a bit backwards. I believe documentation update is in order?

FWIW I was under the impression that EGL_ANDROID_native_fence_sync can
be used in flatland. Although as Rob mentioned... not sure if the
extension is available since the EGL meta seems to block/strip it out.


> On a technical side, the EGL change needs to take into account that
> not all drivers support fences and so it needs to have a fallback to
> old behavior for those which don't.
>

> Other than that, correct me if I'm wrong, but could we just use the
> DRI2 fence extension instead of adding some custom callbacks? I can
> see that a normal client request to create a sync fence would end up
> calling dri2_dpy->fence->create_fence_fd() (if it's present) [1].
> Could we do the same?
>
Reusing existing API would be ideal.

If not, Zhongmin/Yogesh please note:
 - when extending the interface, the version number must be bumped
 - user should check the version and the function pointer prior to
use, falling back to the old scheme
 - get_retrive_fd [barring the typo - retrieve], should have at least
the fd ownership documented

Thanks
Emil