New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775707 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
OOO until 2019-01-24
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Proj-XR



Sign in to add a comment

Android: EGL_ANDROID_native_fence_sync not reported as present

Project Member Reported by klausw@chromium.org, Oct 17 2017

Issue description

We need a way to use this extension even if it's not reported as present. This bug tracks the workaround.

It seems that Android suppresses reporting presence of the EGL_ANDROID_native_fence_sync extension to userspace, it's "strongly recommended" but not required:

https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/eglApi.cpp#130

The eglDupNativeFenceFDANDROID function is exposed in the Android NDK headers as of android-18 (Jelly Bean 4.3.x), but apparently the framework eglApi.cpp code will return EGL_NO_NATIVE_FENCE_FD_ANDROID on systems where the underlying extension is missing, see https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/eglApi.cpp#1850

Philip Rideout recommends:

If it isn't publicized in the EXTENSIONS string, here's what you can do:

- For pre-N versions of Android, assume the extension isn't supported.
- Otherwise, do eglGetProcAddress for eglDupNativeFenceFDANDROID, which should be safe to use it if it is non-null.

Some details:

- Don't rely on the nullness of eglGetProcAddress on older versions of Android, they potentially return a useless wrapper function.
- Don't dlsym() from the driver, it's not recommended any more due to the dynamic driver updates feature in O.
 

Comment 1 by kbr@chromium.org, Oct 17 2017

Cc: zmo@chromium.org
Components: -Internals>GPU Internals>GPU>Internals
Owner: kbr@chromium.org
Status: Assigned (was: Untriaged)
The GL bindings in src/ui/gl/ might need some work to handle somewhat complex (and handwritten?) logic like this. Klaus, let me assign this to you to study and test out possible solutions.

Comment 2 by klausw@chromium.org, Oct 17 2017

kbr@, I've implemented a version of the heuristic in https://chromium-review.googlesource.com/c/chromium/src/+/680314 as of patchset 4 and added you as reviewer. Please let me know what you think.
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 18 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/caa3aed99c42258fd73f34c32f1569d9f4562a66

commit caa3aed99c42258fd73f34c32f1569d9f4562a66
Author: Klaus Weidner <klausw@chromium.org>
Date: Wed Oct 18 20:38:40 2017

GL binding for eglDupNativeFenceFDANDROID

(Part of the "AHardwareBuffer-backed GPUMemoryBuffer" patch series)

This extension supports EGL fences that work cross-process and
cross-share-group. This is needed for working with AHardwareBuffer
objects to synchronize content access via server wait on a file
descriptor-backed fence.

See also https://chromium-review.googlesource.com/679961

https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt

    This extension enables the creation of EGL fence sync objects
    that are associated with a native synchronization fence object
    that is referenced using a file descriptor.  These EGL fence sync
    objects have nearly identical semantics to those defined by the
    KHR_fence_sync extension, except that they have an additional
    attribute storing the file descriptor referring to the native
    fence object.

    This extension assumes the existence of a native fence
    synchronization object that behaves similarly to an EGL fence
    sync object.  These native objects must have a signal status
    like that of an EGLSyncKHR object that indicates whether the
    fence has ever been signaled.  Once signaled the native object's
    signal status may not change again.

BUG= 761432 , 775707 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Id91854e4c85a5b334bf6b8b89cb29069f6e890f7
Reviewed-on: https://chromium-review.googlesource.com/680314
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509856}
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/generate_bindings.py
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_bindings_api_autogen_egl.h
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_bindings_autogen_egl.cc
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_bindings_autogen_egl.h
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_enums_implementation_autogen.h
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_surface_egl.cc
[modify] https://crrev.com/caa3aed99c42258fd73f34c32f1569d9f4562a66/ui/gl/gl_surface_egl.h

Comment 4 by klausw@chromium.org, Oct 19 2017

Status: Fixed (was: Assigned)
Closing since the change is submitted. 

I thought about repurposing this bug as an ExternalDependency to track an Android-side issue to expose the extension correctly, but that doesn't seem helpful. Any fix wouldn't do anything to change existing devices, and even if this were fixed in Android P we'd still need to keep the workaround in place until Chrome decides to stop supporting pre-P Android. Not sure if there's a good way to mark a bug as "check back in 5-10 years to revisit".

Comment 5 by kbr@chromium.org, Oct 19 2017

You could file a low-priority bug that's blocked on this one and assign it to yourself. :)

There's the NextAction field if you want to be reminded at a specific date.
Components: Blink>WebXR

Sign in to add a comment