On 11 July 2017 at 16:23, Tomasz Figa <[email protected]> wrote: > Hi Zhongmin, > > On Tue, Jul 11, 2017 at 11:02 AM, Wu, Zhongmin <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
