waydroid / android_external_mesa3d

Waydroid

Waydroid uses a container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu.

Overview

Waydroid uses Linux namespaces (user, pid, uts, net, mount, ipc) to run a full Android system in a container and provide Android applications on any GNU/Linux-based platform.

The Android system inside the container has direct access to any needed hardware.

The Android runtime environment ships with a minimal customized Android system image based on LineageOS. The image is currently based on Android 11.

Documentation

Our documentation site can be found at docs.waydro.id

Reporting bugs

If you have found an issue with Waydroid, please file a bug.

Get in Touch

If you want to get in contact with the developers please feel free to join the Waydroid groups in Matrix or Telegram.

android_external_mesa3d's Issues

On 23.1.x enable intel xe drivers

enable -Dintel-xe-kmd=enabled when mesa is bumped to 23.1.x will allow running on the new xe driver instead of i915, this allegedly has better vulkan preformance, but mainly people are starting to use it and swapping from I915 to XE is probably not something a user wants to do

NV12 support in libgbm

Hello, opening an issue here to continue the discussion from
waydroid/android_hardware_waydroid#44

Let me recap the context:

I'm working on enabling camera support for Waydroid on a PinephonePro which use an RK3399 SoC.
The RK3399 camera subsystem produces images in NV12 format (only partially supports other formats, NV12 is strongly preferred).

As per Android design, the Camera HAL and the gralloc HAL implementation should agree on what format HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED has to be mapped to (see the above mentioned merge request).

The gralloc_gbm backend does the allocation using libgbm, which is provided by mesa on Waydroid and which as of today doesn't support NV12.

I investigated with upstream #dri-devel last week about this, and what I've been told is that NV12 support is not in upstream mesa because nobody actually used that, and I've been reminded that the 'g' in 'gbm' stands for 'graphic' and not 'generic' so it is probably possible to add NV12 support to mesa, but it's not that anyone really cares as RGB formats are way more common.

So here's my question(s)

1. Is NV12/YCbCr use case supported by Waydroid ? I see this line in the gralloc implementation
   https://github.com/waydroid/android_hardware_waydroid/blob/lineage-18.1/gralloc/gralloc_gbm.cpp#L100
   which makes me think support for some kind of YUV format was needed and it has been implemented by mapping it on what's available on mesa today, with a few hacks here and there to have it working
   https://github.com/waydroid/android_hardware_waydroid/blob/lineage-18.1/gralloc/gralloc_gbm.cpp#L194

This commit actually puzzles me as well waydroid/android_hardware_waydroid@0876013
as I don't see any "mapping" there, as a value of "0" doesn't seem a valid GBM_FORMAT value.

2. ChromiumOS, which has several supported devices on RK3399, has adopted minigbm (which waydroid ships) as their gralloc_gbm backend implementation, which (afaiu) supports allocating NV12 buffers on the Rockchip using a driver-custom ioctl()
   https://github.com/waydroid/android_external_minigbm/blob/lineage-18.1/rockchip.c#L173
   Yes, it requires out-of-tree kernel support at the moment. The reasons why that ioctl is not in the rockchip upstream DRM driver are not fully clear to me yet.

In a case like this, where using minigbm seems more appropriate for the device at hand, would it be possible to instrument the Waydroid build to pick minigbm instead of mesa as libgbm provider ?

All in all, with the current gralloc+mesa implementation, camera support using NV12 format doesn't seem possible to me...

Consider merging 0001-radeonsi-On-Aarch64-force-persistent-buffers-to-GTT.patch

Consider merging this patch to prevent possible graphical glitches on the SolidRun HoneyComb LX2K with an AMDGPU card.

0001-radeonsi-On-Aarch64-force-persistent-buffers-to-GTT-patch.txt

then mv 0001-radeonsi-On-Aarch64-force-persistent-buffers-to-GTT-patch.txt 0001-radeonsi-On-Aarch64-force-persistent-buffers-to-GTT.patch

This patch didn't make it into upstream mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3274