From 7c56a266bab1881cf489669e720a3709207667fb Mon Sep 17 00:00:00 2001 From: John Sebastian Peterson Date: Tue, 18 Feb 2025 15:18:07 +1100 Subject: [PATCH] add lib hardware patch for linked vulkan drivers vulkan.abc.so -> ../egl/libGLES_mali.so MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit the library specifically rejects the symlink on my phone /vendor/lib64/hw/vulkan.ums9230.so -> ../egl/libGLES_mali.so because it is technically in a different name space . this is just laughable but this solves it. i have no objection to this directory tree except drop the duplicate file. perhaps it would work if they linked to -> ../libGLES_mali.so instead . apparently /vendor/lib64/hw/ is a different name space from /vendor/lib64/abc and they specifically test that no files are links between them. must be some kind of mistake /vendor/lib64/ ├── egl │   └── libGLES_mali.so ├── hw │   └── vulkan.ums9230.so -> ../egl/libGLES_mali.so ├── libGLES_mali.so ├── libOpenCL.so.1.2 -> libGLES_mali.so 7 directories, 20 files the two libGLES_mali.so are identical . it is a gigantic file that contains all of CL GL Vulkan. nothing seems to call vendor/lib64/libGLES_mali.so it has become orphaned stranded. a stale copy from the lack of links to it # GL is completely broken speaking of open GL.... suddenly things become murky nothing makes any sense anymore. the file name would imply it directly support OpenGL ES at full speed. glmark can't find any native GL device but finds zink at horrible speed. maybe if i can get glmark2-es2 to work it would be close to Vulkan speed . glmark2-es2 and glmark2-egl fail entirely and hardly anyone seem especially interested in this to my surprise. it seems like an interesting problem I have sun all day and full battery. in the forest in Tasmania at the end of the summer. winter and rain is coming. as usual end of February beginning March week long rain just like home in August September . Vulkan is flawless but open GL all implementations are slow as a snail or broken here are the internal dispatch drivers tree /system/lib64|ack GL ├── libEGL.so ├── libGLESv1_CM.so ├── libGLESv2.so ├── libGLESv3.so all versions of glmark find vendor/lib64/egl/libGLES_mali.so in strace but the only one that works (glx) also find the dispatch driver system/lib64/libGLESv3.so (a copy of libGLESv2.so ) perhaps that is the key to the mystery that egl can't find the right file. i have no idea how mesa is looking for drivers it is probably broken. for some reason the glx build use the system loader instead and it "works" with horrible frame rate strace glmark2-es2 2>&1|ack "EGL|GLES|_mali" openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libEGL.so", O_RDONLY|O_CLOEXEC) = 4 newfstatat(AT_FDCWD, "/vendor/lib64/egl/libGLES_mali.so", no sign of system/lib64/lib*GL* dri2_dpy->fd_render_gpu >= 0" failed strace glmark2 2>&1|ack "_mali|EGL|GLES" newfstatat(AT_FDCWD, "/vendor/lib64/egl/libGLES_mali.so", readlinkat(AT_FDCWD, "/proc/self/fd/28", "/system/lib64/libEGL.so", readlinkat(AT_FDCWD, "/proc/self/fd/67", "/system/lib64/libGLESv3.so", 4096) = 26 GL_VERSION: 3.1 Mesa 24.3.4 this failed again LD_PRELOAD=/system/lib64/libEGL.so glmark2-es2 LD_LIBRARY_PATH=/system/lib64 glmark2-egl Error: eglGetDisplay() failed with error: 0x300c this breaks the vulkan interface that provides the swap chain LD_LIBRARY_PATH=$P/lib glmark2 (/data/data/com.termux/files/home/wsi-twaik/wsi/x11/swapchain.cpp:335) # fix angle dispatch from glvnd not the horrible virtual device this runs without a flaw LD_LIBRARY_PATH=$P/opt/angle-android/gl ~/demos/out/src/egl/opengl/eglinfo -p angle -v but this would not play ball even though strace showed it found the file . whatever i did i could not teach lib glvnd to find my angle drivers which was a disappointment thay would be better. hate ld preload and path $P/share/glvnd/egl_vendor.d/angle.json "library_path" : "libEGL_angle.so" ln -s $P/opt/angle-android/gl/libEGL_angle.so $P/lib/libEGL_angle.so the only reference to angle is from virtual GL and it has no interface to mesa. apt rdepends angle-android Reverse Depends: Depends: virglrenderer-android it is using epoxy to load the angle drivers which is equivalent to ld Library path without the epoxy patch virgl_test_server_android --angle-gl is equivalent to LD_LIBRARY_PATH=$P/opt/angle-android/gl virgl_test_server --use-egl-surfaceless --use-gles LIBGL_ALWAYS_SOFTWARE=1 GALLIUM _DRIVER=virpipe garbage_app68 this can handle a hodge podge of apps that use ancient copy and paste cody with no clue what they are doing and only testing on NVIDIA drivers. dosbox and furmark for instance the GLES lock in seems like a crutch because surface less report native open GL support . although angle does not so maybe it is doomed to fail . i don't know if there is any way to render the full GL specification with angle since it's only for browsers eglinfo -v -p surfaceless EGL_RENDERABLE_TYPE: opengl,opengles,opengles2 EGL_SURFACE_TYPE: pbuffer but someone has to fix the mesa dispatch for angle the virtual GL nonsense is BS. how could that possibly be better outside of an emulator when you can call the driver directly instead without any overhead. --- tur-on-device/libhardware-vulkan/build.sh | 82 +++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 tur-on-device/libhardware-vulkan/build.sh diff --git a/tur-on-device/libhardware-vulkan/build.sh b/tur-on-device/libhardware-vulkan/build.sh new file mode 100644 index 0000000000..df1c6c9c37 --- /dev/null +++ b/tur-on-device/libhardware-vulkan/build.sh @@ -0,0 +1,82 @@ + +TERMUX_PKG_DESCRIPTION="load linked drivers from a different folder fe vulkan.ums9230.so -> ../egl/libGLES_mali.so" +TERMUX_PKG_VERSION=0 +TERMUX_PKG_LICENSE="WTFPL" +TERMUX_PKG_SRCURL=( +# git+$HOME/libhardware +# git+$HOME/core +# git+$HOME/logging +git+https://github.com/john-peterson/platform_hardware_libhardware +git+https://android.googlesource.com/platform/system/core +git+https://android.googlesource.com/platform/system/logging +) +TERMUX_PKG_GIT_BRANCH=(mali main main) +# TERMUX_PKG_BUILD_DEPENDS="bionic-host" + +termux_step_get_source() { + # /cache + # I have to do everything myself apparently + set +e + j=0 + for i in "${TERMUX_PKG_SRCURL[@]}"; do + url=${i:4} + branch=${TERMUX_PKG_GIT_BRANCH[j]} + # test -z "$i" && target=. + git clone -q --branch $branch --depth 5 $url + ((j++)) + done + mkdir $TERMUX_PKG_SRCDIR + cp -r * $TERMUX_PKG_SRCDIR/ + # TERMUX_PKG_SRCDIR=$TERMUX_PKG_SRCDIR/$(basename ${TERMUX_PKG_SRCURL[0]}) + # exit; +} + +termux_step_host_build() { + # Can someone fix all these bugs + if ! $TERMUX_ON_DEVICE_BUILD;then + source $TERMUX_SCRIPTDIR/script/termux_step_host_build.sh + termux_step_host_build + fi + } + +termux_step_setup_toolchain() { + # God knows what this is doing + if $TERMUX_ON_DEVICE_BUILD;then + READELF=readelf + STRIP=strip + else + source $TERMUX_SCRIPTDIR/script/termux_step_setup_toolchain +termux_step_setup_toolchain + fi +} + +termux_step_configure() { :; } +termux_step_make() { + # /build + if ! $TERMUX_ON_DEVICE_BUILD;then + echo trying to link with libvndksupport.so off device will fail Can you run this on device instead and upload the packet much appreciated + fi + +cd $TERMUX_PKG_SRCDIR + +clang *libhardware/hardware.c -g -I *libhardware/include -I core/include -I core/libvndksupport/include -I logging/liblog/include -shared -l cutils -l vndksupport -l log -o $TERMUX_PKG_BUILDDIR/libhardware.so +} + +termux_step_make_install() { + mkdir -p $TERMUX_PKG_MASSAGEDIR/$TERMUX_PREFIX/lib + cp $TERMUX_PKG_BUILDDIR/* $TERMUX_PKG_MASSAGEDIR/$TERMUX_PREFIX/lib/ +} + +termux_step_install_license(){ + # this thing is completely broken + :; +} + +termux_step_extract_into_massagedir() { + # this is trying to tar my entire system + :; +} + +# termux_step_post_massage() { :; } + +