Shared objects of OpenGLES 3 and OpenCL

[phoenix]

Sorry , Myy , I have been trying to deal with the system , using all of your excellent examples , yet in vain.
My tinker is configured to work with 1280X720@ 60 Hz and woks very well. Your sample program as well as this basic program from khronos yields the same results:

//Doing it the khronos way
const char *client_extensions = eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
if (client_extensions)
{
    printf("Got Client extensions:\n %s\n", client_extensions);
}

Do you, at least, get the extensions printed correctly ?

Display* pX11Display;
EGLDisplay *pEGLDisplay;

pX11Display = XOpenDisplay(NULL);
if (!pX11Display)
{
    printf("Error opening the display\n");
    exit(-1);
}
printf("Got a valid display pointer: %p\n", pX11Display);

I guess that it fails at that point ?

Just for information, what does :

Code:

ls -l /usr/lib/libGLESv2.so.2 /usr/lib/libEGL.so.1

returns ?

Anyway, you could try the following instead, in order to get a display, if the EGL_EXT_platform_base extension is supported :

Code:

   char const * __restrict const supported_extensions =
       eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
   
   if (supported_extensions
       && strstr(supported_extensions, "EGL_EXT_platform_base")) {
       
       LOG("Using eglGetPlatformDisplayEXT !\n");
       PFNEGLGETPLATFORMDISPLAYEXTPROC get_platform_display = NULL;
       get_platform_display =
           reinterpret_cast<PFNEGLGETPLATFORMDISPLAYEXTPROC>(
               eglGetProcAddress("eglGetPlatformDisplayEXT")
           );

       if (get_platform_display != nullptr) {
           egl_display_ = get_platform_display(
               EGL_PLATFORM_X11_KHR, native_display_, NULL
           );
       }
       
       if (!egl_display_) {
           LOG("eglGetDispayPlatformEXT failed...\n");
       }
       
   }
   else {
       LOG("eglGetDisplayPlatformEXT seems unsupported\n");
   }

LOG being equivalent a to fprintf(stderr, message, format) call here.

---

Ok, I've created a quick Gist showing how to use the extension, and fallback to eglGetDisplay :

https://gist.github.com/Miouyouyou/f2585...ca691527ee

Thanks again for the reply , Myy.
I do know the extension mechanism and the extension mechanism works great. I have added your code to my simple example , yet in vain.
Here is my code:

Code:

int main()
{
    //Doing it the khronos way
    const char *client_extensions = eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
    if (client_extensions)
    {
        printf("Got Client extensions:\n %s\n", client_extensions);
    }
    Display* pX11Display;
    EGLDisplay *pEGLDisplay;
    PFNEGLGETPLATFORMDISPLAYEXTPROC get_platform_display = NULL;
    get_platform_display = (PFNEGLGETPLATFORMDISPLAYEXTPROC)
        eglGetProcAddress("eglGetPlatformDisplayEXT");
    pX11Display = XOpenDisplay(NULL);
    if (!pX11Display)
    {
        printf("Error opening the display\n");
        exit(-1);
    }
    printf("Got a valid display pointer: %p\n", pX11Display);

    pEGLDisplay = eglGetDisplay( pX11Display);
    printf("EGL Display pointer is now %p\n", pEGLDisplay);
    pEGLDisplay = get_platform_display(    EGL_PLATFORM_X11_KHR, pX11Display, NULL);
    printf("EGL Display pointer with platform is now %p\n", pEGLDisplay);

    EGLint major, minor;
    if (!eglInitialize(pEGLDisplay, &major, &minor))
    {
        printf("Failed to initialize, the error is %x\n", eglGetError());
    }
    else
    {
        printf("Success !");
    }

    exit(0);
}

As you see, I deliberately called eglGetDisplay and get_platform_Display from your example, to check out if the pointers are different ,only to get this:

Got Client extensions:
     EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_platform_x11      EGL_EXT_platform_x11 EGL_KHR_platform_gbm

Got a valid display pointer: 0x80ca1600
EGL Display pointer is now 0x80caebe8
EGL Display pointer with platform is now 0x80caebe8
Failed to initialize, the error is 3001

Notice, please that the EGL Display pointer gets the same value with or without the platform function
And once again , initialization fails.
Just to be on the safe side : I am working with the latest versions of TinkerBoard. thus have applied:
sudo apt update
sudo apt upgrade
sudo apt autoclean
sudo apt autoremove
though the last two are totally unnecessary . Seems the Tinker takes care of redundant material removal itself.
Heaving executed :

Code:

xdpyinfo |grep "of root"

I get:

  depth of root window:    24 planes

Which means the window I am using is fully capable of handling GLES.

As for the links:
The tinker hosts all the .so objects of the GLES library inside:
/usr/lib/arm-linux-gnueabihf/

here is a quote of the return values for the linked files :

linaro@linaro-alip:/usr/lib/arm-linux-gnueabihf$ ls -l libGL*

lrwxrwxrwx 1 root root     14 Mar 21 15:02 libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 301792 Mar 21 15:02 libGL.so.1.2.0
lrwxrwxrwx 1 root root     10 Jan 16 11:28 libGLESv2.so -> libmali.so
lrwxrwxrwx 1 root root     28 Jan 16 11:37 libGLESv2.so.2 -> libmali-midgard-r9p0-r0p0.so
lrwxrwxrwx 1 root root     28 Jan 16 11:37 libGLESv2.so.2.0.0 -> libmali-midgard-r9p0-r0p0.so
lrwxrwxrwx 1 root root     16 Sep 18  2016 libGLEW.so.2.0 -> libGLEW.so.2.0.0
-rw-r--r-- 1 root root 468916 Sep 18  2016 libGLEW.so.2.0.0
lrwxrwxrwx 1 root root     15 Sep 13  2015 libGLU.so.1 -> libGLU.so.1.3.1
-rw-r--r-- 1 root root 272216 Sep 13  2015 libGLU.so.1.3.1


ls -l libmali.so 
lrwxrwxrwx 1 root root 28 Jan 16 11:37 libmali.so -> libmali-midgard-r9p0-r0p0.so

since all libraries are with root ownership and root group , I also sudo'd my application and got the same result

also sudo su, to turn root , just in case, and got the same result


And to add to the confusion:
glxdemo,glxgears,glxheads,glxinfo (which are fixed functionality OpenGL as far as I can recall ) execute flawlessly ....


Any further insights perhaps ?
Thanks again.

[Myy]

Hmm, the GLX tools mostly use GLX, instead of EGL, so I'm not sure they would help pinpoint EGL issues. And they also use OpenGL, instead of OpenGL ES, so I'm almost sure that they'll use Mesa OpenGL software drivers.
So it's entirely possible that none of these tools use the Mali drivers at all. MESA software renderer will generally work in every case.

You might want to test with the extra Mesa utils, (mesa-tools-extra or mesa-utils-extra, or something like that), that provide es2info and es2gears.

Actually, let's try to rule out the probability that you've got some drivers issues, since I've tried my sample on my MiQi, without any X11 connection available, and eglGetDisplay was still able to get a display correctly... So the result of eglGetDisplay don't mean a lot. It's a good thing it if succeeds, but even then, we can't be sure that it got something usable.

Try to download es2info and es2gears from the Mesa utils extra, or glmark2, or something that clearly use OpenGL ES and EGL on X11. If they execute flawlessly, then you might want to try recording their EGL and OpenGL calls using apitrace, and analyze the trace afterwards, to understand how they've been able to initialize and use the display.

---

Also, just to be sure, could you try to do 'ldd ./yourEGLBinary' and provide the output here ? Just to be sure that the binary is linked to the correct libraries.

[phoenix]

Thanks again Myy,
Seems the analysis you provided was right. The mesa-utils-extra is indeed there as of the installation of the Asus Tinker , and all of the es* applications fail at the eglInitialize Phase.
Alas !
Doesn't seem there is anyone at ASUS who listens, does it now ?
phoenix

[Myy]

Thanks again Myy,
Seems the analysis you provided was right. The mesa-utils-extra is indeed there as of the installation of the Asus Tinker , and all of the es* applications fail at the eglInitialize Phase.
Alas !
Doesn't seem there is anyone at ASUS who listens, does it now ?
phoenix

Not that I'm aware of. However,

First, check that /dev/mali0 exists.
Second, check that /dev/mali0 is accessible by your current user.
Third, try some others Mali X11, notably the ones provided by Rockchip here : https://github.com/rockchip-linux/rk-roo...hf/libmali

Remember to backup the libraries before.

OR

Download the firefly's Mali X11 drivers from here :
https://developer.arm.com/-/media/Files/...1x11tar.gz
( https://developer.arm.com/products/softw...user-space )

Then unpack the archive somewhere. This should create a x11 folder with all libEGL and libGLES links pointing to a local libmali.so . Try these drivers using

Code:

LD_LIBRARY_PATH=/path/to/unpacked/drivers/x11 es2gears

If that works, replace es2gears with your binary.

If that does not work, download  libmali-midgard-r13p0-r0p0.so from here https://github.com/rockchip-linux/libmal...-gnueabihf , rename it libmali.so and put it in the non-working firefly's X11 drivers folder (something like mv libmali-midgard-r13p0-r0p0.so /path/to/unpacked/drivers/x11/libmali.so ), and retry.

Note that if everything fail, you might want to shutdown X by going to a terminal (CTRL+ALT+F1), shutting down gdm, then, in root, do

# export LD_LIBRARY_PATH=/path/to/unpacked/drivers/x11
# xinit

X11 might hang with some drivers though, so be prepared to reboot if it feels that the board is stuck.



If everything failed to that point... Welcome to the KMS/Wayland world ! Where only weston works ! Yay...

[phoenix]

Thanks again Myy,
Seems the analysis you provided was right. The mesa-utils-extra is indeed there as of the installation of the Asus Tinker , and all of the es* applications fail at the eglInitialize Phase.
Alas !
Doesn't seem there is anyone at ASUS who listens, does it now ?
phoenix

Not that I'm aware of. However,

First, check that /dev/mali0 exists.
Second, check that /dev/mali0 is accessible by your current user.
Third, try some others Mali X11, notably the ones provided by Rockchip here : https://github.com/rockchip-linux/rk-roo...hf/libmali

Remember to backup the libraries before.

OR

Download the firefly's Mali X11 drivers from here :
https://developer.arm.com/-/media/Files/...1x11tar.gz
( https://developer.arm.com/products/softw...user-space )

Then unpack the archive somewhere. This should create a x11 folder with all libEGL and libGLES links pointing to a local libmali.so . Try these drivers using

Code:

LD_LIBRARY_PATH=/path/to/unpacked/drivers/x11 es2gears

If that works, replace es2gears with your binary.

If that does not work, download  libmali-midgard-r13p0-r0p0.so from here https://github.com/rockchip-linux/libmal...-gnueabihf , rename it libmali.so and put it in the non-working firefly's X11 drivers folder (something like mv libmali-midgard-r13p0-r0p0.so /path/to/unpacked/drivers/x11/libmali.so ), and retry.

Note that if everything fail, you might want to shutdown X by going to a terminal (CTRL+ALT+F1), shutting down gdm, then, in root, do

# export LD_LIBRARY_PATH=/path/to/unpacked/drivers/x11
# xinit

X11 might hang with some drivers though, so be prepared to reboot if it feels that the board is stuck.



If everything failed to that point... Welcome to the KMS/Wayland world ! Where only weston works ! Yay...


Thanks again for the reply.
The problem has been solved by ASUS support.
Seems that sudo apt upgrade overwrites the basic 1.8 version's drivers, killing the es2/3 support at instance.
I thus was instructed to re-install a clean image of the debian 1.8 version and ....presto, everything works

I even installed and checked glmark2-es2 , which got me a slow. bad and aliased result of 87 ,(with all CPU's cores heavily loaded and a boiling chip)  but that's a start.
i have gl2Gears up and running. 
Next target : Attempt to execute Mali's SDK Applciations , which after first make fall with a different Error, but that's another story.
Thank you all for your kind support.

[Myy]

Glad you got it covered !

For the speed issue, you might want to try this :


Go to /sys/class/misc/mali0/device/devfreq/*.mali/
Try to get the available frequencies by running:

cat available_frequencies

This should return something like :

100000000 200000000 300000000 400000000 500000000 600000000

Then take the lowest frequency and highest frequency (100000000 and 600000000 here) and set them in min_freq and max_freq like this :

echo 100000000 > min_freq
echo 600000000 > max_freq

Then, set up the polling interval to something like 20 ms

echo 20 > polling_interval