[Feature Request] proroot Vulkan Runtime Bridge 검토 제안

[hansm629]

@coderredlab
안녕하세요. 선생님!
proroot의 host APK integration 방향과 관련해서 한 가지 아이디어를 제안드려봅니다.

이 제안에서는 전체 기능을 proroot Vulkan Runtime Bridge라 칭하고,
내부를 크게 다음 두 부분으로 나누는 구조를 생각하고 있습니다.

1. guest-side Vulkan bridge ICD
   - glibc Linux rootfs 안에서 Vulkan loader가 보는 ICD

2. host-side backend
   - Android host APK 안에서 Android Vulkan stack을 다루는 부분
   - 이 부분은 vulkan-wrapper-android 계열 로직을 기반으로 구성

핵심은 guest glibc 환경에서 Android vendor libvulkan.so를 직접 로드하지 않는 것입니다.

대신 guest Linux는 Vulkan bridge ICD를 통해 요청을 보내고, host APK 안의 proroot Vulkan Runtime Bridge가 Android bionic 환경에서 Android Vulkan loader / NDK libvulkan.so를 통해 vendor Vulkan driver로 dispatch를 전달하는 구조입니다.

배경

기존 Termux > proot 환경에서는 GPU 가속이 큰 한계였습니다.

Adreno 계열은 Turnip/Freedreno KGSL 덕분에 어느 정도 가능성이 있지만,
Mali / Xclipse / PowerVR / 기타 vendor-only GPU에서는 일반 Linux용 Mesa Vulkan driver가 사실상 없는 수준입니다.

하지만 대부분의 Android 기기에는 Android용 vendor Vulkan driver가 이미 존재합니다.

문제는 이 Android Vulkan stack이 bionic, Android Vulkan loader, ANativeWindow, gralloc, sync fence 등 Android 환경에 강하게 묶여 있어서 glibc Linux guest에서 직접 사용하기 어렵다는 점입니다.

따라서 Android Vulkan stack은 host APK 쪽에서 사용하고, guest Linux에는 Vulkan Runtime Bridge 형태로 제공하는 방식이 현실적이지 않을까 생각했습니다.

vulkan-wrapper-android 기반으로 브릿지 구성

처음에는 X11 WSI 구현을 위해 vulkan-wsi-layer 통합만 생각했는데, 다시 보니 vulkan-wrapper-android 계열을 기반으로 잡는 편이 더 좋아 보였습니다.

vulkan-wsi-layer는 X11/Wayland WSI를 안드로이드 밴더 Vulkan 드라이버에 구현만 하지만,
vulkan-wrapper-android는 아래와 같은 점 때문에 proroot Vulkan Runtime Bridge의 host-side backend 기반으로 적합해 보입니다.

- Android Vulkan stack을 X11/Wayland 환경에서 쓰기 위한 wrapper 구조
- Termux-X11 X서버 환경과 Winlator 계열 에뮬레이터에서 X11 WSI 호환 및 zero-copy 검증
- X11 WSI 뿐 아니라 게임 구동에 필요한 instance / extension / 관련 처리도 어느 정도 고려됨
- 밴더 Vulkan 드라이버에서 비활성화된 BCn 텍스쳐를 강제 활성화 시키는 DBUG 옵션이 있어 하드웨어 상 지원 시, 작동 가능
- GPU별 quirk / workaround 반영 가능성이 있음
- Turnip 미지원 SoC에서 Android vendor Vulkan을 활용할 수 있는 기반이 될 수 있음

즉 이 제안에서 vulkan-wrapper-android는 별도 외부 컴포넌트가 아니라, proroot Vulkan Runtime Bridge 내부의 host-side backend 구현 기반으로 보는 것이 적절해 보입니다.

목표

• guest glibc가 Android vendor Vulkan library를 직접 로드하지 않는 구조
• guest Linux 앱은 Vulkan bridge ICD를 통해 host-side bridge에 접근
• host-side bridge는 Android Vulkan loader / NDK libvulkan.so를 통해 vendor driver로 dispatch 전달
• host-side backend에 vulkan-wrapper-android 계열의 WSI / quirk / wrapper 로직 활용
• Mesa Zink를 통해 Linux OpenGL 앱을 Android Vulkan 위에서 실행
• clvk를 통해 Vulkan 기반 OpenCL 3.0 호환 경로도 검토
• Turnip 미지원 SoC에서도 Android vendor Vulkan + Zink 경로 확보

예상 구조

Android Host APK
├─ proroot runtime
├─ X11 / Wayland display backend
│
└─ proroot Vulkan Runtime Bridge
   ├─ guest-side Vulkan bridge ICD
   │  ├─ libvulkan_proroot_bridge.so
   │  └─ runtime ICD JSON
   │
   ├─ bridge IPC layer
   │  └─ socket / shared memory / FD
   │
   └─ host-side backend
      ├─ vulkan-wrapper-android based backend
      ├─ Android Vulkan loader / NDK libvulkan.so
      ├─ vendor Vulkan driver dispatch
      ├─ X11 / Wayland / Android Surface WSI handling
      ├─ ANativeWindow / Surface
      ├─ AHardwareBuffer / gralloc / sync fence
      └─ GPU-specific quirks / workarounds

        ↓

proroot Guest Linux, glibc
├─ Linux app
│  ├─ OpenGL app
│  ├─ Vulkan app
│  └─ OpenCL app, via clvk
│
├─ Mesa / graphics stack
│  ├─ Zink
│  ├─ Vulkan loader
│  ├─ clvk / OpenCL ICD
│  └─ llvmpipe fallback
│
└─ env/profile
   ├─ VK_DRIVER_FILES
   ├─ GALLIUM_DRIVER=zink
   ├─ MESA_LOADER_DRIVER_OVERRIDE=zink
   └─ OCL_ICD_VENDORS, optional for clvk

호출 흐름 예시

### OpenGL via Zink
Linux OpenGL app
→ Mesa Zink
→ Vulkan loader
→ guest-side Vulkan bridge ICD
→ bridge IPC layer
→ host-side vulkan-wrapper-android based backend
→ Android Vulkan loader / NDK libvulkan.so
→ vendor Vulkan driver
→ GPU


### Native Vulkan
Linux Vulkan app
→ Vulkan loader
→ guest-side Vulkan bridge ICD
→ bridge IPC layer
→ host-side vulkan-wrapper-android based backend
→ Android Vulkan loader / NDK libvulkan.so
→ vendor Vulkan driver


### OpenCL via clvk
Linux OpenCL app
→ OpenCL ICD loader
→ clvk
→ Vulkan loader
→ guest-side Vulkan bridge ICD
→ bridge IPC layer
→ host-side vulkan-wrapper-android based backend
→ Android Vulkan loader / NDK libvulkan.so
→ vendor Vulkan driver
→ GPU

guest-side ICD 구성 예시

guest rootfs 내부에는 runtime 전용 Vulkan ICD JSON을 두는 방식이 좋을 것 같습니다.

/opt/proroot-gfx/
├─ lib/
│  └─ libvulkan_proroot_bridge.so
│
├─ icd.d/
│  └─ proroot_android_vulkan_bridge_icd.aarch64.json
│
├─ OpenCL/
│  └─ vendors/
│     └─ clvk.icd
│
└─ env/
   └─ android-vulkan-bridge.env

### 예상 ICD JSON:
{
  "file_format_version": "1.0.1",
  "ICD": {
    "library_path": "/opt/proroot-gfx/lib/libvulkan_proroot_bridge.so",
    "api_version": "1.3.0"
  }
}

### 예상 guest env:
export VK_DRIVER_FILES=/opt/proroot-gfx/icd.d/proroot_android_vulkan_bridge_icd.aarch64.json
export PROROOT_VK_BRIDGE_SOCKET=/tmp/proroot-vk.sock
export PROROOT_GPU_BACKEND=android-vulkan-wrapper

export MESA_LOADER_DRIVER_OVERRIDE=zink

# Optional: OpenCL via clvk
export OCL_ICD_VENDORS=/opt/proroot-gfx/OpenCL/vendors

여기서 libvulkan_proroot_bridge.so는 Android vendor libvulkan.so가 아니라 guest glibc용 bridge ICD입니다.

실제 Vulkan dispatch는 host APK 안의 proroot Vulkan Runtime Bridge host-side backend가 Android Vulkan loader / NDK libvulkan.so를 통해 vendor Vulkan driver로 전달하는 구조를 생각하고 있습니다.

MVP / 초기 검증 목표

처음부터 완전한 게임 호환성을 목표로 하기보다는, 기본적인 Vulkan / OpenGL / OpenCL 테스트가 통과되는 정도만 되어도 충분히 의미가 있을 것 같습니다.

### Vulkan
vulkaninfo
vkcube
vkmark

### OpenGL via Zink
glxinfo -B
glxgears
glmark2
glmakr2-es2

### OpenCL via clvk
clinfo
clpeak

이 정도가 통과되면, guest Linux에서 host Android Vulkan runtime을 통해 기본적인 Vulkan / OpenGL / OpenCL 경로가 성립한다는 것을 확인할 수 있을 것 같습니다.

기대 효과

• libhybris 없이 Android Vulkan stack 활용 가능
• glibc guest와 bionic Vulkan stack을 같은 프로세스에 섞지 않아도 됨
• Turnip/Freedreno가 없는 SoC에도 GPU 가속 가능성 확보
  • Mali
  • Xclipse
  • PowerVR
  • 기타 vendor-only GPU
• Android Vulkan + vulkan-wrapper-android 기반 host-side backend + Zink 조합으로 Linux OpenGL 앱 가속 가능성
• clvk를 통한 Vulkan 기반 OpenCL 3.0 호환 경로 확보 가능성
• GPU별 quirk / workaround를 host-side backend에서 관리 가능
• Steam / Proton / FEX, Blender, Chromium, 게임 런타임, compute workload 등으로 확장 가능

정리

해당 제안은 proroot core에 GPU stack을 직접 넣자는 의미는 아니며,

host APK가 제공하는 proroot Vulkan Runtime Bridge를 guest Linux에서 사용할 수 있도록 하는 공통 bridge / contract를 검토 요청드리는 것입니다.

장기적으로는 비루팅 Android에서 Linux GUI / GPU / compute workload를 실행하는 데 중요한 기반 기능이 될 수 있을 것 같으며 Termux > Proot에선 불가능했던 Mali / Xclipse / PowerVR 계열의 GPU 가속이
proroot에선 가능해질것으로 전망합니다.

만약 이것이 구현 가능하다면 MediaCodec와 NNAPI에 대한 런타임 브릿지 구현도 가능하지 않을까 생각되네요!

해당 범위는 proroot의 기본 기능이 안정화가 완료된 후 구현될
후순위 일감이라고 생각되어서 찬찬히 고려해주셔도 될거같습니다!

검토 부탁드립니다~!

proroot 개발에 기여해주셔서 감사드립니다!

[coderredlab]

@hansm629

선생님, 이거 정말 좋은 아이디어입니다. 솔직히 본문 읽으면서 "아, 이거다" 싶었습니다. 제가 지금 정확히 막혀 있던 지점을 그대로 풀어주는 제안이라 더 그렇습니다.

제가 막혀 있던 지점

proroot의 v1.2.0 / v1.2.1 작업하면서 Adreno는 lfdevs/mesa-for-android-container fork 를 통해 KGSL 기반 가속 path를 확보했지만, Mali / Xclipse / PowerVR 쪽은 사실상 답이 없는 상태였습니다. 직접 시도해본 길마다 막혔습니다:

• vendor blob 직접 로드 — Mali libGLES_mali.so / libvulkan_*.so 가 Bionic + ANativeWindow + gralloc + system_property cache + scudo malloc 까지 깊이 의존. glibc guest에서 끌어오려면 사실상 Bionic 전체를 흉내내야 해서 dead end.
• KMS/DRM 경로 — /dev/mali0 SELinux 차단, /dev/dri/renderD128 도 untrusted_app 차단. Panfrost / PanVK 같은 mesa Mali driver 도 막혀서 의미가 없습니다.
• virgl + ANGLE 우회 — 현재 사용 중인 path 이지만 socket IPC + ANGLE GL→Vulkan 변환 오버헤드가 가속 이득을 거의 다 갉아먹습니다. glmark2 측정 시 swrast (CPU llvmpipe) 와 거의 동등하게 나옵니다.

즉 Adreno 외 chip에서 의미 있는 GPU 가속이 architectural ceiling 에 막혀 있는 상태였습니다.

이 제안이 정확히 그걸 푸는 path 입니다

선생님이 그리신 그림 — guest는 bridge ICD만 보고, host APK 의 backend 가 Android Vulkan loader 를 통해 vendor driver 로 dispatch — 이게 정확히 위 세 가지 ceiling을 다 우회합니다:

• vendor blob 을 guest 에 끌어오지 않음 → Bionic ABI 추격 문제 자체가 없어짐
• KMS/DRM 의존이 없음 → Android Vulkan loader 가 알아서 vendor driver 호출
• GL→Vulkan 변환 오버헤드 없음 → mesa Zink 가 guest 안에서 돌고 결과만 Vulkan 으로 forward

게다가 virgl/venus 가 데스크탑 가상화에서 이미 양산 중인 동일 아키텍처라는 점이 안전망입니다. mesa 의 Venus driver 가 사실상 guest-side ICD 의 절반을 이미 구현해두고 있어서, 이 위에 Android Vulkan loader 를 backend 로 붙이는 작업이 합리적인 출발점이 됩니다. vulkan-wrapper-android 를 host-side backend 기반으로 잡자는 점도 정확합니다 — WSI / quirk / 게임 런타임 호환성을 새로 작성하지 않고 가져다 쓸 수 있습니다.

proroom 의 first-class consumer 모델과 정확히 맞물립니다

이게 가장 큰 매력입니다. proroot 의 long-term positioning 은 Termux 비의존 Linux userland runtime 라이브러리 이고, 그 위에 자체 host APK (proroom — Ubuntu + Xfce + 자체 디스플레이 backend) 가 first-class consumer 로 올라가는 그림입니다.

선생님이 제안하신 host-side backend 가 proroom 의 Kotlin 컴포넌트로 그대로 들어갈 자리 입니다. proroot core 가 ABI를 가지지 않고 host APK 가 backend 를 가지는 구조라서, 본질이 깨끗합니다. proroot 자체에는 거의 변경이 없습니다 — guest 의 socket / FD passing / dma-buf ioctl 같은 부분은 이미 path translation / FD inherit 으로 지원되고 있어서, 추가될 부분은 ICD JSON 검색 경로 등 작은 부속 정도입니다.

제가 지금 계획 중인 proroom 에 이 아이디어를 포함해서 만들어 보겠습니다. 선생님이 그려주신 host-side backend 가 proroom 의 GPU 트랙 의 핵심 컴포넌트로 들어가는 그림입니다. 위에 정리한 architectural ceiling 때문에 Mali / Xclipse 류 chip 의 가속 path 가 마땅치 않아서 고민이 많았는데, 이 제안이 정확히 그 매듭을 풀어줍니다.

공수와 우선순위

선생님이 본문에 적어주신 우선순위 — "core 안정화 이후 후순위" — 그대로가 맞다고 봅니다. 실제 공수는 적지 않습니다:

• Vulkan API marshalling (pNext chain 포함) 이 전체 공수의 약 70%. 단 mesa Venus driver 가 guest-side 대부분을 커버해서 절반은 공짜에 가깝습니다.
• 남은 30% 가 AHardwareBuffer / VK_ANDROID_external_memory_android_hardware_buffer / sync_file 통합과 Linux WSI (X11/Wayland) → Android Surface present 경로 작성.
• vendor driver 별 quirk 누적 비용은 vulkan-wrapper-android 가 흡수해주는 부분이 큽니다.

진행 시점은 v1.x line 의 user-reported 회귀 사이클이 마무리된 다음, proroom 의 GPU 가속 트랙 으로 들어갈 예정입니다. MediaCodec / NNAPI 런타임 브릿지 확장도 정확히 같은 contract 위에 올라가는 자연스러운 후속 작업이라, 같이 그림 안에 들어갑니다.

좋은 제안 정말 감사드립니다. 이슈 본문이 거의 그대로 설계 문서로 쓰일 수 있을 만큼 정리가 잘 되어 있어서, proroom 작업 들어갈 때 이 이슈를 그대로 reference 로 들고 가게 될 것 같습니다.

[hansm629]

@coderredlab
검토해주셔서 감사합니다!

드디어 많은 유저들의 염원인
proot/chroot/LXC 환경에서 비 스냅드래곤 SoC들의 GPU 가속에 대한 숙제가 풀릴거 같네요!ㅠㅠ

다행히도 제가 제안드린 vulkan-wrapper-android의 경우 이미

• Termux bionic 네이티브 프로그램 > Termux-X11 X서버
• Winlator(bionic) 계열 에뮬레이터 > 내장 X서버

위와 같은 두 환경에서
AHB(Android Hardware Buffer)를 통한 zero-copy가 구현되어있어서 DRI3가 아주 잘작동되는 것으로 검증되었습니다!

vulkan-wrapper-android가 이미 안드로이드 밴더 Vulkan 드라이버에 대해 아래와 같이

• Vulkan Loade 역할
• X11/Wayland WSI 구현
• 기타 인스탄스 및 익스텐션 구현

등등을 하고 있어서

proroot Vulkan Runtime Bridge에서 vulkan-wrapper-android가 통합되고
경로가 깨지지 않는다면 큰 문제없이 glibc guest에서도 DRI3가 작동할것으로 추정되고 있네요!

마침 제가 Xclipse 940 디바이스도(Samsung Galaxy S24+) 보유하고 있어서
구현되면 적극 테스트 지원드리겠습니다!