[Package]: real libEGL, libGLESv1_CM, libGLESv2, libGLESv3

[twaik]

Package description

EGL/GLESv1/GLESv2/GLESv3 libraries

Home page URL

No response

Source code URL

https://android.googlesource.com/platform/frameworks/native

Packaging policy acknowledgement

• [X] I have read and understand the Packaging Policy.

Additional information

Hi. A problem of using hardware accellerating in termux is simple: it is not possible to create platform's compatible native windows and/or hardware buffers and use them with existing libEGL/GLESv1/GLESv2. But we can use android-emugl and anbox sources to create something like GLES streaming to another activity or program. Android Studio's emulator and Anbox already use emugl so I think it is possible to use it in our project. I already started porting anbox source but I can not check if it works because I can not build Android's EGL/GLES/system core libraries without Android's build system, compiler reports thousands of errors. Ubuntu and Debian have debhelper scripts for building it. Is there someone who can port those?

[twaik]

@xeffyr Can you please help with this?

[xtkoba]

Is this different from enabling egl, gles1 and gles2 in the mesa package?

https://github.com/termux/x11-packages/blob/f7c869e8d46ae64bc10f4b81677af88568a425be/packages/mesa/build.sh#L20-L22

[twaik]

It is different. And I do not khow to make mesa use android-emugl.

[twaik]

Android's EGL, GLESv1, GLESv2 and GLESv3 libraries are common for all Android devices. It is forbidden to device manufacters to change them because it is a part of ABI. Instead of writing EGL/GLES implementation they write drivers using VNDK (vendor native development kit). Emugl imeplements driver. And that is a reason I need EGL/GLES imeplemented in Android and not mesa.

[xtkoba]

Oh, thanks for the explanation. I am not familiar with vendored libraries other than Bionic.

[Grimler91]

Aren't these libraries already available in /system/lib and the android ndk?

$ ls /system/lib/libGLESv*
/system/lib/libGLESv1_CM.so  /system/lib/libGLESv3.so
/system/lib/libGLESv2.so

[grimler@grimler android-r23b-api-24-v5]$ ls sysroot/usr/lib/aarch64-linux-android/24/libGLES*
sysroot/usr/lib/aarch64-linux-android/24/libGLESv1_CM.so
sysroot/usr/lib/aarch64-linux-android/24/libGLESv2.so
sysroot/usr/lib/aarch64-linux-android/24/libGLESv3.so

Edit: or are you asking for help to create a Makefile for the sources to simplify creating a library with various changes?

[twaik]

Aren't these libraries already available in /system/lib and the android ndk?

/system/lib libraries loads drivers from /vendor/lib/egl and this behaviour can not be changed. Libraries in Android ndk are just stubs so they are useless. My idea is to port Android's real libraries patched to use termux's pathes. That will let us use android-emugl as a driver.

Edit: or are you asking for help to create a Makefile for the sources to simplify creating a library with various changes?

I am asking for help with creating Makefile/meson/CMake files to make it work inside termux. Every time I am trying to do that I am having more and more compilation errors.

I have debhelper files (zip) used to create debian packagess and I hope they can help to port dependencies.

[DLC01]

wouldn't using mesa drivers be easier here? mesa's Zink driver has been ported to termux see here it provides hardware accelerated opengl/gles over vulkan. the issue is that I couldn't get it to compile on ci i always seem to run into issues

[twaik]

If mesa can draw over Android's activity it is easier. But if not we should try to port Android's sources.

[DLC01]

I don't think mesa drivers are able to draw over Android's activity, but it can be used with Xwayland and termux-x11 and maybe Xvfb+x11vnc

[twaik]

Copying image from memory fragment to video memory is resource-intensive operation. There is a big difference in drawing yellow 1024x1024 px square and copying/transfering its image to GLES and then drawing it. You are right about Xvfb+x11vnc, mesa can be used there, but termux-x11 is designed to be as light as possible and to use the fastest mechanisms that are possible to use (I know it is not the fastest app, my fault). emugl will let us make drawing frames zero-copy. But if you know the way to use emugl with mesa I do not mind to use it.

[DLC01]

From what i've read isn't emugl supposed to be used for translating desktop GL to GLES?

[twaik]

As far as I know translator is optional if you have native GLES.

[DLC01]

wouldn't that still pose an problem because it will only provide an android EGL surface which x11 apps will not be able to use?

[twaik]

I want to use something like libhybris code. Briefly: there is an extension called drihybris. When you try to create EGL surface on top of X11 window it creates native buffer and draws it as picture inside a window. It has a speed problem (memory fragment should be copied and rendered at least twice) which should be solved in case if we use glamor.

[twaik]

Looks like I found a simpler way to port it. Termux requires Android 7.0 as minimal version so we can use source of android-platform-system-core package based on Android 7.0. It has less dependencies (libcutils, libutils, liblog, libui) and has simpler code (and not dependent on VNDK). What do you think guys? UPD: Android EGL/GLES implemetation of branch android-7.0.0_r33 has less dependencies, not android-platform-system-core.

[twaik]

I found out that mesa can be built with Android NDK and AOSP. But it is useless for us because it replaces drivers of device. And this mesa driver is being opened by Android's EGL/GLESv2.

[Heasterian]

I'm here to come back to talk a bit about Zink and Turnip combo. It can be build directly in Termux and work without replacing device driver and it should work as Zink is loading vk driver here and afaik it can run on any surface that supports basic extensions (including Termux-X11 and Xephyr, I tried both). I would add Zink to list on the top as it probably will be best option to get desktop OpenGL in Termux.

[twaik]

Android's egl/gles opens secondary drivers so they can be easily used in one environment. Of cource after porting. So we will be able to switch driver using graphical menu.

[bylaws]

Aren't these libraries already available in /system/lib and the android ndk?

/system/lib libraries loads drivers from /vendor/lib/egl and this behaviour can not be changed. Libraries in Android ndk are just stubs so they are useless. My idea is to port Android's real libraries patched to use termux's pathes. That will let us use android-emugl as a driver. It can with some patches, I have a library to do that for VK

[twaik]

Maybe you will say I am mad but I have san angeles test working on PC using libGLES_android, libEGL and libGLESv1_CM libraries built from Android's source, output to X11 window using XShmImage extension and glReadPixels calls. My sources are a bit ugly because I stored all the dependencies inside the project directory but I think it can be ported to termux.

Screenshot

[twaik]

If there is anybody who wants to see how to port Android's EGL and GLES to Ubuntu (not termux) you can check this: android_egl_for_ubuntu.tar.gz A bit ugly but you can see all the patches (most of them there). Looks like I am starting to port emugl there and after that to termux-x11

[jaisingh-js]

Hi sorry if i am breaking any rule but i want to work on this. Can you tell me where can i start?

[twaik]

You can try to build emugl and make it work on top of my EGL. Any other part is a bit more complicated.

[twaik]

~~Is there anyone who can help?~~ ~~It stucks in pthread_mutex_lock in platform/frameworks/native/opengl/libs/EGL/egl.cpp:209, but without mutex it segfaults...~~

~~android_egl_for_ubuntu.tar.gz It is for desktop linux, not for termux.~~ ~~Building on top of desktop linux is needed for desktop linux in prooted/chrooted environments.~~ Fixed

Looks like it works with android_renderer android_egl_for_ubuntu.tar.gz I still did not decide how exactly I will draw a surface on a renderer's side... It should be interesting...

[twaik]

I just mention it here... https://github.com/termux/x11-packages/issues/31 https://github.com/termux/termux-packages/issues/2107 Anyway drawing on pbuffer surface should work even without using emugl/mesa/anything else.

[twaik]

I found a few things:

1. emugl uses simple read call in it's command queue. That means we can not pass there file descriptors. That means we can not bind ashmem region to our virtual "native" buffers so we will have at least three copy processes here: from GLES to emugl server (glReadPixels), from emugl server to X11 program (using simple read/write calls) and the last one is from buffer got with read inside emugl's library to XShmImage. That is very bad situation but anyway it is much faster then without acceleration at all...
2. We do not need to use emugl if we are not in chroot/proot. We can simply make bindings to real egl library and hook some calls (just like libhybris). Everything we need is to create pbuffer or pixmap surface and then draw it on XShmImage. That will be the most fast thing we can try.
3. In the case of chroot/proot container we need emugl with render server in process not touched by proot/chroot. And then use the same thing: pixmap/pbuffer+XShmImage.
4. All of it will work even without acceleration support in Xorg/Xwayland/other Xserver.

[licy183]

Hi, I'm working on porting chromium to Termux these days, and it seems that chromium uses swiftshader and ANGLE to provide full software implementation of OpenGL ES. If I understand correctly, swiftshader provides an CPU-based implementation of vulkan, and ANGLE could translate OpenGL ES operation to vulkan calls. So is it possible to let these libraries to provide libEGL, libGLESv1_CM and libGLESv2?

[DLC01]

Couldn't ANGLE also theoretically run atop the system vulkan driver to Provide hardware accelerated OpenGL ES

[licy183]

Couldn't ANGLE also theoretically run atop the system vulkan driver to Provide hardware accelerated OpenGL ES

libvulkan.so in Android doesn't contain symbols like vkCreateXcbSurfaceKHR but it has symbols like vkCreateAndroidSurfaceKHR. As we use OpenGL to render a X11 window, I don't think vulkan from Android is able to use.