-
Notifications
You must be signed in to change notification settings - Fork 10
Description
@leegao
hello sir!
I’d like to request a glibc-vulkan-wrapper project that runs in a glibc environment!
The bionic-vulkan-wrapper already supports the X11 WSI instance extension and DRI3(for Termux-X11).
The idea is to implement libhybris that enables interoperability between bionic libc and glibc, along with a libhybris-specific AHardwareBuffer implementation, and then wrap the existing bionic-vulkan-wrapper to create a glibc-vulkan-wrapper.
The architecture diagram I have in mind is as follows.
App (glibc; e.g., vkcube / vkmark / blender(vulkan backend))
│
▼
Vulkan Loader (glibc) — libvulkan.so.1 (Khronos Loader)
│
│ VK_ICD_FILENAMES=/usr/lib/vulkan/icd.d/libvulkan_glibc_wrapper_icd.json
▼
┌──────────────────────────────────────────────────────────────────────────────┐
│ libvulkan_glibc_wrapper.so ← (single ICD loaded by glibc) │
│ ───────────────────────────────────────────────────────────────────────── │
│ [F1] ICD Frontend (glibc) │
│ • Exports vk_icdGetInstanceProcAddr / vkGetInstanceProcAddr / │
│ vkNegotiateLoaderICDInterface, etc. │
│ • Dispatch entry points for KHR surface/xlib/xcb/swapchain │
│ │
│ [F2] WSI-X11 Client (glibc) │
│ • Uses libX11/libxcb │
│ • Implements vkCreateXlibSurfaceKHR / vkCreateXcbSurfaceKHR │
│ • Prepares DRI3/Present parameters │
│ │
│ [F3] AHardwareBuffer Wrapper (glibc side) │
│ • Implements VK_ANDROID_external_memory_android_hardware_buffer │
│ • dma-buf FD import/export helper APIs │
│ • Internally calls [F4] to reach bionic AHB/Gralloc │
│ │
│ [F4] libhybris Core (built-in: static or dynamic) │
│ • glibc ↔ bionic ABI bridge (TLS/errno/struct shims) │
│ • Loads bionic symbols/libs (HYBRIS_* search paths) │
│ │
│ [F5] bionic Payload Loader (via hybris) │
│ • dlopen: libvulkan_wrapper.so (bionic-vulkan-wrapper) │
│ └─ dlopen: vendor Vulkan driver (e.g., vulkan.samsung.so) │
│ │
│ ───────────────────────────────────────────────────────────────────────── │
│ Inbound ABI : glibc(Loader/App) → [F1] │
│ Bridge (int) : [F1/F2/F3] → [F4] → [F5] (bionic domain) │
│ Outbound paths: │
│ • WSI Present → Termux-X11 (pure X11 server; DRI3/Present; dma-buf RX) │
│ • AHB/Gralloc → Android bionic AHB (alloc/import/export) │
│ • GPU exec → Vendor driver → Android kernel (dma-buf/sync_fence) │
└──────────────────────────────────────────────────────────────────────────────┘
│ │ │
│ (DRI3 Present + │ (AHB alloc/import, │ (GPU execution, memory
│ dma-buf FDs & fences) │ dma-buf FDs flow) │ sharing, sync_fence)
▼ ▼ ▼
Termux-X11 (X11 server) AHB/Gralloc (bionic) Android Kernel (GPU, dma-buf, fences)
High-level call flow
- App (glibc) → Loader (glibc) → libvulkan_glibc_wrapper.so [F1] (vk* enters ICD).
- [F1/F2/F3] call into [F4] libhybris, which bridges to [F5] bionic-vulkan-wrapper.
- [F5] drives the Vendor Vulkan driver for device/swapchain/image creation.
- WSI (X11/DRI3) path exchanges dma-buf FDs & sync fences with Termux-X11 (pure X11 server) for on-screen present.
- AHB path: [F3] glibc AHB wrapper ↔ [F4] ↔ bionic AHB/Gralloc for alloc/import/export.
- Buffers and synchronization converge in the Android kernel (dma-buf + sync_fence).
For reference, I used the packages provided here:
https://github.com/kde-yyds/android-vulkan-bridge
Using those packages (libhybris, ahb-wrapper, sysvk, vulkan-wsi-layer), I managed to load Vulkan in a PRoot-Distro Debian/Arch Linux environment on a non-rooting device.
However, due to a swapchain issue, on-screen rendering did not work.
In theory, using libhybris should make it fully feasible to use Vulkan from a glibc environment.
One point of caution is that vendor drivers differ by Android SoC manufacturer, so libhybris may fail to hook correctly, which seems to cause TLS (thread-local storage) errors.
(This is probably why on-screen rendering is failing for me on the Xclipse 940.)
It looks like there is also a pull request in progress to fix this kind of TLS access issue:
libhybris/libhybris@f47e718
If we account for these aspects, it actually seems the glibc-vulkan-wrapper could be implemented more easily than expected.
If this project is successful, Vulkan acceleration should be usable in Termux-native glibc (e.g., mobox), Winlator glibc, and PRoot/Chroot Linux environments!