EGL X11 support

[tareksander]

• [ ] shared memory Pixmap as a fallback option
  • [x] Image flipping and color conversion on the CPU
  • [ ] Image flipping and color conversion in shaders, via a separate shader render (to not mess with applications calling readPixels or trying to copy from FB into a texture).
• [ ] putImage as a fallback fallback for when using TCP sockets? Low priority, on getDisplay missing shared pixmaps are recognized and the display fails, falling back to Mesa. When you have to transmit frames over the network, CPU rendering shouldn't be the issue anyways, so it's fine.
• [x] extracting the DMABUF fd from a HardwareBuffer and use that for shared memory
  • [ ] Currently low performance, not known why.
  • [ ] Try the format matching the X11 format, else fall back to CPU or GPU post-processing
• [x] double buffering
• [ ] implement eglSwapInterval for 0 and 1

[twaik]

There is mechanism called SurfaceTexture which implements both consumers and producers. I see the way to use it without JNI (or emulate JNI without JVM) but there is a problem with interacting with server. It will require connecting directly to X server's Binder, but there is no documented way to register broadcast/intent receiver without real Context.

[licy183]

This fork of libhybris implements x11: https://github.com/gemian/libhybris

Hope that it is helpful for you...

[twaik]

Libhybris implements WSI using custom ANativeWindow implementation. We are avoiding this.

[twaik]

I think we should port this + this (mechanisms used in mesa's EGL) or this (used in vulkan). It should be faster and more reliable since it is native code of X11 implementations.

[twaik]

Hello. Is there any progress?

[tareksander]

I have the dispatch function generator finished now, including EGL extensions. Now I need to override the reported EGL extensions to the actually supported ones and the GLES version to fixed 2.0 for now and I can start testing. I'll copy the X11 implementation form the C version pretty much exactly, but without hardware buffers for now, but I'll add some performance improvements at the cost of GLES spec non-compliance, that can be tuned via env vars.

Optimizations:

• Modifying the vertex shader returns to flip the axis if needed.
• Modify the fragment shader to swap around the color order.

That may interfere with programs that use glReadPixels, so I want to use env vars to control this. However doing the format conversion directly on the graphics chip should perform better, and better than using several buffers and doing it in stages via post-processing. That is what I'll have to do in Vulkan, since SPIR-V shaders aren't really modifiable easily.

[tareksander]

I'm testing if the Android EGL passthrough works, but the emulator keeps crashing lol. Let's see if restarting my system helps, Nvidia drivers on Linux are a bit flaky sometimes.

[twaik]

Any crashlogs?

[tareksander]

First eglinfo -p android gives this in the console: /buildbot/src/android/emu-34-release/hardware/google/gfxstream/host/gl/glestranslator/GLES_V2/GLESv2Imp.cpp:glTexSubImage2D:3892 error 0x502. Second one crashes and gives this:

0409 16:40:59.000945   14963 ColorBufferGl.cpp:1029] Failed to import external memory object with error: 1282
E0409 16:40:59.001235   14963 ColorBuffer.cpp:95] Failed to import memory to ColorBufferGl:223
F0409 16:40:59.002899   14963 FrameBuffer.cpp:1133] FATAL in createColorBufferWithHandleLocked, err code: 4300000000: Failed to create ColorBuffer:223 format:36194 framework-format:0 width:0 height:0
Received signal 6
#0 0x7f5c08aa0efa <unknown>
#1 0x7f5c08aa0a34 <unknown>
#2 0x7f5c0c05b050 <unknown>
#3 0x7f5c0c0a9e2c <unknown>
#4 0x7f5c0c05afb2 gsignal
#5 0x7f5c0c045472 abort
#6 0x7f5c0e06c6d6 <unknown>
#7 0x7f5c0e06c6a6 emugl::AbortMessage::~AbortMessage()
#8 0x7f5c000b91d2 gfxstream::FrameBuffer::createColorBufferWithHandleLocked()
#9 0x7f5c000b8e32 gfxstream::FrameBuffer::createColorBuffer()
#10 0x7f5c000dbe83 gfxstream::renderControl_decoder_context_t::decode()
#11 0x7f5c000a3657 gfxstream::RenderThread::main()
#12 0x7f5c0e017f7d android::base::Thread::thread_main()
#13 0x7f5c0c0a8134 <unknown>
#14 0x7f5c0c1287dc <unknown>
  r8: 00007f5b1a932d00  r9: 0000000000000073 r10: 0000000000000008 r11: 0000000000000246
 r12: 0000000000000006 r13: 00007f5b1a932d48 r14: 00007f5b1a932e48 r15: 0000562eff7afa40
  di: 0000000000003913  si: 0000000000003a73  bp: 00007f5b1a9376c0  bx: 0000000000003a73
  dx: 0000000000000006  ax: 0000000000000000  cx: 00007f5c0c0a9e2c  sp: 00007f5b1a932be0
  ip: 00007f5c0c0a9e2c efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: fffffffe7ffbfedf cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Seems like I have to fix whatever is wrong with the EGL calls, because it causes the host implementation to crash lol.

[twaik]

• [ ] Try the format matching the X11 format, else fall back to CPU or GPU post-processing

Probably that is not very right since in that case you must flip bytes. But you can try to allocate AHardwareBuffer with format 5 (which stands for non-SDK AHARDWAREBUFFER_FORMAT_B8G8R8A8_UNORM). I use it in Termux:X11 and it seems to be supported on all devices. Best choice for our case since it is compatible with GLES textures and does not need separate convert processing.

[twaik]

I am not so sure but probably combining the new ability of Termux:X11 to use AHardwareBuffers + using AHARDWAREBUFFER_USAGE_CPU_READ_RARELY + AHARDWAREBUFFER_USAGE_CPU_WRITE_NEVER flags (without using AHARDWAREBUFFER_USAGE_CPU_READ_OFTEN or AHARDWAREBUFFER_USAGE_CPU_WRITE_OFTEN) may improve performance.