vc4: Android HWUI rendering on RPI3 freezes screen

[babyimp]

Hi,

I'm working with Android Things in Google.
When HWUI rendering is enabled on RPI3 where Android Things DP5.1 is installed, app screen is frozen.

Steps to reproduce:

1. Install Android Things DP5.1 on RPI3
2. Boot RPI3
3. Change the system property
   % adb connect xx.xx.xx.xx
   % adb shell setprop persist.sys.ui.hw true
4. Reboot RPI3

Now, booting animation is okay, but IoTLauncher is not rendered properly. Then, ANR occurs.
According to ANR log (attached) for IoTLauncher, HWUI renderer seems to wait for other to signal fence.

This issue might be more relevant to mesa, but I hope to get some hints to solve this issue here.

anr_log.txt

[anholt]

Could you come up with a testcase for piglit or intel-gpu-tools that exposes whatever fencing issue you have?

I actually suspect that your UI may be trying to use extensions that don't exist -- we don't have android native fences exposed (our implementation is all implicitly synced, so we've never needed explicit fencing).

[babyimp]

You mean, unless mesa supports android native fences, it may not be possible to enable HW UI rendering?

[anholt]

From the log you appear to be running drm_hwcomposer, which has the following code:

  // These extensions are all technically required but not always reported due
  // to meta EGL filtering them out.
  if (!HasExtension("EGL_KHR_image_base", egl_extensions))
    ALOGW("EGL_KHR_image_base extension not supported");

  if (!HasExtension("EGL_ANDROID_image_native_buffer", egl_extensions))
    ALOGW("EGL_ANDROID_image_native_buffer extension not supported");

  if (!HasExtension("EGL_ANDROID_native_fence_sync", egl_extensions))
    ALOGW("EGL_ANDROID_native_fence_sync extension not supported");

If you're running drm_hwcomposer, then you really need those extensions and the fact that it tries to run at all without them exposed is a bug imo.

The next step in implementing native_fence_sync is to build some piglit tests we can run that do actual rendering, not just API error validation (upstreamed DEQP or VK-GL-CTS tests doing so would also be fine).

[babyimp]

This issue has been unintentionally solved after upgrading to 4.9 and tuning selinux policy for sw_sync.

[stschake]

4.9 has no vc4 dma fence support, which is what you want for sync_file and that in consequence makes EGL_ANDROID_native_fence on the mainline kernel interface impossible.

So you might want to check why you are running drm_hwcomposer, because without the EGL extension it can't do it's optimized GL composition and the moment it has to fallback to that, you will crash.

I have a branch for vc4 native fence lying around, but its only been tested on kmscube and you obviously need a kernel with the dma fence support first (see torvalds/linux@cdec4d3)