[Mesa-dev] [RFC PATCH] egl/android: Dequeue buffers inside EGL calls

Tapani Pälli tapani.palli at intel.com
Mon Apr 3 05:08:41 UTC 2017



On 04/02/2017 07:38 PM, Mauro Rossi wrote:
>
>
> 2017-03-30 16:17 GMT+02:00 Emil Velikov <emil.l.velikov at gmail.com
> <mailto:emil.l.velikov at gmail.com>>:
>
>     On 30 March 2017 at 11:55, Tomasz Figa <tfiga at chromium.org
>     <mailto:tfiga at chromium.org>> wrote:
>     > Android buffer queues can be abandoned, which results in failing to
>     > dequeue next buffer. Currently this would fail somewhere deep within
>     > the DRI stack calling loader's getBuffers*(), without any error
>     > reporting to the client app. However Android framework code relies on
>     > proper signaling of this event, so we move buffer dequeue to
>     > createWindowSurface() and swapBuffers() call, which can generate
>     proper
>     > EGL errors. To keep the performance benefits of delayed buffer
>     handling,
>     > if any, fence wait and DRI image creation is kept delayed until
>     > getBuffers*() is called by the DRI driver.
>     >
>     Thank you Tomasz.
>
>     I'm fairly confident that this should resolve the crash [in
>     swap_buffers] that Mauro was seeing.
>     Mauro can you give it a test ?
>
>
> After applying last version of Tomasz patch,
> I could not boot nougat-x86, the same way as per Tapani get_back_bo()
> throwing and EGL_BAD_ALLOC
> which is a show stopper for surfaceflinger
>
> So I reverted [1] and now I can boot and I also see the black wallpaper
> like Tapani.
> dumpsys SurfaceFlinger output shows a buffer allocated,
> but for some reason both HWC and GLES composition (used in nougat-x86)
> show black wallpaper.
>
> ----
> h/w composer state:
>   h/w composer not present and enabled
> Allocated buffers:
> ...
> 0x7b60f301e380: 29440.00 KiB | 2880 (2944) x 2560 |        5 |
> 0x00000900 | com.android.systemui.ImageWallpaper
> ...
> Total allocated (estimate): 54728.50 KB
> ----
>
>
>
>     Not that huge of an expert on the Android specifics, so just a
>     humble request:
>     Can we seek the code resuffle (droid_{alloc,free}_local_buffer,
>     other?) separate from the functionality changes ?
>
>     -Emil
>
>
> I'd also kindly request to confirm the test environment used to verify
> Tomasz patch v2,
> which in my understanding has been the following, common between
> ChomiumOS and Android-IA:
>
>   * minigbm based gralloc
>   * dma FDs for buffers
>   * kernel based explicit fences with FDs
>   * HWC2 for compositing
>   * (?) Render nodes - but I don't know if/when they are used
>
> In android-x86 (nougat-x86) situation is the following:
>
>   * drm_gralloc based gralloc
>   * buffer handles
>   * Not 100% sure about sync/fences, but I don't recall about using
>     explicit fences with FDs
>   * GLES for compositing
>   * we don't use render nodes
>
> Pardon me if this seems a long checklist or if it's not 100% accurate,
> but I would assume that this patch should just work Out-Of-The-Box with
> android-x86 (nougat-x86)
> even if most of CrOS/Android-IA optimizations are not (yet) used there.
>
> Is this assumption correct?
>
> In this moment the only way to boot nougat-x86 is to revert [1]
> but besides this and black wallpaper, which both require investigation,
> I've not seen any particular regression.
>
> Thanks for feeedbacks
> Mauro
>
> PS: Question for Tapani: if you apply Tomasz patch and revert [1], do
> you still see the segfault in Android-IA?

No, that patch is not needed anymore as it seems now there is always a 
back buffer available when coming to droid_swap_buffers. I tested with 
the 3DMark app that caused that crash.


> [1]
>  https://cgit.freedesktop.org/mesa/mesa/commit/?id=4d4558411db166d2d66f8cec9cb581149dbe1597
> <https://cgit.freedesktop.org/mesa/mesa/commit/?id=4d4558411db166d2d66f8cec9cb581149dbe1597>
>
>
>

// Tapani


More information about the mesa-dev mailing list