3D rendering with libhybris drivers

[NotKit]

xf86-video-fbturbo seems to provide 3D acceleration glue for Mali drivers. The question is, is it possible to write such glue for drivers not to meant to work with Xorg?

libhybris is a compatibility layer allowing to use Android libraries under glibc Linux userspace. It has support for Wayland integration, but not Xorg.

I tried (NotKit/libhybris@b389ac4) to output rendered OpenGL ES buffers via XShmPutImage, but it's slow. What's the best direction to try implementing zero-copying (or at least single-copy) 3D acceleration glue for Xorg/fbturbo? Android's gralloc allows to share graphics buffers between processes, and is used instead of DRM stack, which might be a problem for using DRI2, but it seems Mali did this as well with libUMP.

[ssvb]

For getting zero copy, you need to find a way to render output to a hardware overlay/plane/layer if it is supported by the graphics controller in your hardware. If you can do this, then a large part of the work is already done.

The fbturbo DDX implements hooks, which allow us to always know if a window is fully visible or overlapped by something else. In the former case we can use the hardware layer as a shortcut and have zero copy. In the latter case we disable the layer, take a fallback path and do 1 copy. Assuming that nothing else overlaps the window of your 3D application most of the time, this optimization provides a nice performance improvement.

DRI2 passes around an opaque handle and should not not impose any restrictions on the implementation. But the client side of the mali code is closed source, so we can't easily use it as reference.

[ssvb]

BTW, what kind of hardware it that?

[NotKit]

Thanks, I will check how that's done in fbturbo DDX. Android has another API - hwcomposer, which could be probably utilized for that.

Basically generic mobile/phone tablet (with Qualcomm or MediaTek SoC) which came with Android and has SailfishOS (https://wiki.merproject.org/wiki/Adaptations/libhybris) or Hallium ported.

[mittorn]

Is it related to xorg driver? hwcomposer is running with libhybris separately and android EGL implementation does not use x11 dri.

[NotKit]

@mittorn the question was how libhybris could be integrated with x11 dri.

[NotKit]

It's probably offtopic, but can framebuffer output be completely avoided in favor of overlay API? Basically, If hwcomposer is to be used, I want Xorg to render into gralloc-allocated buffer (like shadowFB?), which could be then feed to EGL or hwcomposer itself. Is it possible to get hooks for Xorg (not DRI2) buffer swaps? I suppose by default it uses single thundered fb and writes to memory directly.

[mittorn]

Yes, iy should be possible as non-framebuffer drivers do