Trying to get P2D/P3D working on ARM dev Board [Mali-400]

edited May 31 in Raspberry PI

I am trying to get P2d mode on a Allwinner based board having MALI-400 GPU. Default renderer works ok. But when i try P3D i get :

Caught handled GLException: EGLGLXDrawableFactory - Could not initialize shared resources for EGLGraphicsDevice[type .egl, v0.0.0, connection :0.0, unitID 0, handle 0x0, owner true, ResourceToolkitLock[obj 0x75ff7c, isOwner true, <b21f42, 8d940c>[count 1, qsz 0, owner <main-SharedResourceRunner>]]] on thread main-SharedResourceRunner [0]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource( [1]: [2]: Caused[0] by GLException: Failed to created/initialize EGL display incl. fallback default: native 0x0, error 0x3008/0x3000 on thread main-SharedResourceRunner [0]: jogamp.opengl.egl.EGLDisplayUtil.eglGetDisplayAndInitialize( [1]: jogamp.opengl.egl.EGLDisplayUtil.access$300( [2]: jogamp.opengl.egl.EGLDisplayUtil$1.eglGetAndInitDisplay( [3]: [4]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createEGLSharedResourceImpl( [5]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource( [6]: [7]: libGL error: unable to load driver: libGL error: driver pointer missing libGL error: failed to load driver: mali_drm libGL error: unable to load driver: libGL error: driver pointer missing libGL error: failed to load driver: mali_drm

I checked with lsmod - i have mali_drm driver loaded [I am running Legacy Kernel armv6hf (3.4) with fbturbo video driver for Xorg 1.18 and binary]

Running glmark2-es2 benchmarking software gives me 150fps+ :

OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-400 MP GL_VERSION: OpenGL ES 2.0 All other softwares also seems to detect OpenGLES just fine.

Do i need to make some modifications to Processing to make it find the right libs ? eg. replace core.jar / jogamp gluegen?



  • @solidsnake The support for Mali GPUs is not yet in a released version of Processing. Try replacing your core.jar with this file in the mean time!

  • edited May 30

    @gohai i replaced my core.jar file with yours, but honestly i am not seeing any difference...but thanks a lot for your support anyway !

    when ever i run a sketch on any of my ARM boards (i have dozens and dozens of them !), xorg+java eats up all my cpu and the SoC gets insanely hot :(

    i also saw a arm64 version of processing in your website. did u build it urself? can i download it and test it on my H5/H6 boards ?

  • Answer ✓

    @solidsnake: Perhaps you need to disable "glx" as done in the first post here. I don't have hardware to test, unfortunately .

    SOC getting hot: don't think we can do anything about this.

    ARM64 version: we had one, but then realized that Oracle's JDK for arm64 seem to all be of the "headless" kind, meaning that they are not suitable for running Processing. You can run it with OpenJDK, and it will work, but so far I haven't found time to test and put together a release with it.

  • @solidsnake: Did disabling "glx" indeed make it work for you?

  • edited June 1

    @gohai, No, it did not make any difference. Infact i tried many other suggestions found online, nothing worked.

    Considering Mali-400 was released in 2008, more than 10 years have passed...even so, i see developers are still confused about how to approach/solve this "Mali issue".

    I am completely fine using binary blobs instead of an open-source solution. i currently use all my ARM boards in a headless environment. and probably will use a low-power x86 board like brix/UpSquared for the Processing based project.

    I even ran Processing on 586 class 433Mhz AMD Geodes / Vortex DX2 and a VGA Monitor, on a 16mb Linux based OS.

    People blame chinese SoC vendors for gpu driver problems, but i think the only one responsible is ARM and Google. really frustrating :(

  • @solidsnake

    Yes, I too wish the situation in this regard would be a bit more uplifting!

    But we do see people successfully use P3D graphics on the CHIP which too has a Mali-400, so it might just be worth in investing in better-supported SBC boards when it comes to graphics support.

Sign In or Register to comment.