[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