Shared objects of OpenGLES 3 and OpenCL

[phoenix]

Greetings forum.
I installed the TinkerOS1.8 strech version , seem to be working great , 
did sudo apt update
sudo apt upgrade
seems I am working great with the new version.
One of the things which triggered the purchase of the TinkerBoard is the fact it is supposed to support OpenGL ES3.0 and OpenCL 1.1
Looking into the .so libraries, I could not find Neither the .so file for the OpenGLES 3.0 , though its .h files are there , nor did I mange to find any .h file for the OpenCL library. Is there any link to download them so that I may start working with the Board ?

the files which are currently present on my machine are only of the old versions of OpenGL ES:

./usr/lib/arm-linux-gnueabihf/gstreamer-1.0/libeglgles.so
./usr/lib/arm-linux-gnueabihf/libGLESv2.so.2
*****NO libGLESV3.so********

and the OpenCL .SO files ( which are there...)
./usr/lib/arm-linux-gnueabihf/libMaliOpenCL.so
./usr/lib/arm-linux-gnueabihf/libOpenCL.so
******NO cl.h --> May I just download them from khronos.org? ************



Thank you .

[knuxyl]

Greetings forum.
I installed the TinkerOS1.8 strech version , seem to be working great , 
did sudo apt update
sudo apt upgrade
seems I am working great with the new version.
One of the things which triggered the purchase of the TinkerBoard is the fact it is supposed to support OpenGL ES3.0 and OpenCL 1.1
Looking into the .so libraries, I could not find Neither the .so file for the OpenGLES 3.0 , though its .h files are there , nor did I mange to find any .h file for the OpenCL library. Is there any link to download them so that I may start working with the Board ?

the files which are currently present on my machine are only of the old versions of OpenGL ES:

./usr/lib/arm-linux-gnueabihf/gstreamer-1.0/libeglgles.so
./usr/lib/arm-linux-gnueabihf/libGLESv2.so.2
*****NO libGLESV3.so********

and the OpenCL .SO files ( which are there...)
./usr/lib/arm-linux-gnueabihf/libMaliOpenCL.so
./usr/lib/arm-linux-gnueabihf/libOpenCL.so
******NO cl.h --> May I just download them from khronos.org? ************



Thank you .

Yeah the hardware supports it, but I'm not sure if the software has been developed yet. If you're not seeing it, probably not.

[Myy]

libGLESv3.so is not a standard GLES library name. GLES 3.x calls are provided through the libGLESv2.so library. You'll have to request the appropriate context through EGL to access GLES 3.x functionalities though.

There should be a GLES3/gl3.h , GLES3/gl31.h and GLES3/gl32.h. If they're not available, you might want to install the appropriate mesa development headers.

For OpenCL, mesa headers could also help, or you can copy the ones provided by ARM in their Compute Library git repository https://github.com/ARM-software/ComputeLibrary .

[mac-l1]

libGLESv3.so is not a standard GLES library name. GLES 3.x calls are provided through the libGLESv2.so library. You'll have to request the appropriate context through EGL to access GLES 3.x functionalities though.

There should be a GLES3/gl3.h , GLES3/gl31.h and GLES3/gl32.h. If they're not available, you might want to install the appropriate mesa development headers.

For OpenCL, mesa headers could also help, or you can copy the ones provided by ARM in their Compute Library git repository https://github.com/ARM-software/ComputeLibrary .

hi all,
myy is right. the gpu libraries for rockchip is acually just one library and all libEGL* libGLES* libOpenCL* libgbm* are softlinked to this one and it also includes the GLES3.1 ABI. for the different rockchip platforms you can find them here:
https://github.com/rockchip-linux/libmal...-gnueabihf
the lib used for X11 on rk3288 is mostly libmali-midgard-r9p0-r0p0.so and that one also works on higher versioned mali drivers in kernel.
these are packaged into deb packages here: https://github.com/rockchip-linux/rk-roo...hf/libmali
the header files, also for opencl, can be found here:
https://github.com/rockchip-linux/libmal...ip/include
hope this helps.
cheers -- mac-l1

[frankwu100]

Hi, 

Code:

$ ls -l /usr/lib/arm-linux-gnueabihf/libGLES*
lrwxrwxrwx 1 root root 10 Jan 16 09:28 /usr/lib/arm-linux-gnueabihf/libGLESv2.so > libmali.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 -> libmali-midgard-r9p0-r0p0.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 -> libmali-midgard-r9p0-r0p0.so

So, you can link libGLESv3.so to libmali.so like libGLESv2.so.

Code:

$ sudo ln libmali.so libGLESv3.so

I hope this helps you.

[Brian Beuken]

Hi, 

Code:

$ ls -l /usr/lib/arm-linux-gnueabihf/libGLES*
lrwxrwxrwx 1 root root 10 Jan 16 09:28 /usr/lib/arm-linux-gnueabihf/libGLESv2.so > libmali.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 -> libmali-midgard-r9p0-r0p0.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 -> libmali-midgard-r9p0-r0p0.so

So, you can link libGLESv3.so to libmali.so like libGLESv2.so.

Code:

$ sudo ln libmali.so libGLESv3.so

I hope this helps you.

Awesome I will have to try this out soon, but does it actually work on the hardware or is it emulated? It seems at the moment all the OGLES is not running at hardware level and is painfully slow. 
I won't be able to test this for a couple of weeks but am curious to know.
Also does anyone know when will a full feature GLES3.1 lib we available as part of the standard image?

[phoenix]

Hi, 

Code:

$ ls -l /usr/lib/arm-linux-gnueabihf/libGLES*
lrwxrwxrwx 1 root root 10 Jan 16 09:28 /usr/lib/arm-linux-gnueabihf/libGLESv2.so > libmali.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 -> libmali-midgard-r9p0-r0p0.so
lrwxrwxrwx 1 root root 28 Jan 16 09:37 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 -> libmali-midgard-r9p0-r0p0.so

So, you can link libGLESv3.so to libmali.so like libGLESv2.so.

Code:

$ sudo ln libmali.so libGLESv3.so

I hope this helps you.

Awesome I will have to try this out soon, but does it actually work on the hardware or is it emulated? It seems at the moment all the OGLES is not running at hardware level and is painfully slow. 
I won't be able to test this for a couple of weeks but am curious to know.
Also does anyone know when will a full feature GLES3.1 lib we available as part of the standard image?

Well, Thank you all for yout good tips. Seems that the one from Myy with the .v2 hiding inside it the features of ES V3 was good. all you need to do is to define a nice extension and the commands are opened and compile.
Heaving said that , Compile does not mean execute. Seems every sample I tried activating fails . Took the sampels from :http://opengles-book.com/samplecode.html , worked hard to compile them , the X11 system creates the window yet the OpenGL ES fails to initialize ( NO feedback here from the GLES system , it just fails) . Yesterday I tried downloading the Mali SDK for ARM developers , found some mistakes in the cmake files, corrected them , compiled it all (https://developer.arm.com/products/softw...opengl-es) and once again , the OpenGL ES initialization failed. Seems that this installation arrives in two possible compile versions, One is for some FBTor FTDB or some other special drivers and this is why it won't init. I also found other files for compilation using the X11 libraries, yet I must admit , this is tedious. Any good advice/working basic code for OpenGL ES3.0 for the Asus tinker would be appreciated . I am talking about the working HW drivers version , not emulation, as the MALI chip from RockChip is clearly stated to support these features.
By the way : Suppose miraculously I will be able to set everything to work ( don't know how , but suppose) . I am quite knowledgable in 3D Graphics and OpenCL (That's my job in the the last 20 years ) is there any public Asus place ( Like Rasbperry PI has) inside which I can post my samples and tips?
Thanks again.
Phoenix.

[Myy]

OpenGL issues are very hard to pinpoint. It could be due to many things but one of the most common issue is that the EGL context was not properly setup. Setting up the context can be quite a pain, and doing it wrong will generally lead to several issues like no Depth Testing, for example.

Try to abuse eglGetError, in order to pinpoint the issue. Some frameworks having macros like CHECK_EGL(egl_instruction(params)) that expand to a few log calls using the value of eglGetError() after executing the instruction.

The major pitfalls are :

• Forgetting to ask for an OpenGL ES 3.0 or 3.1 *ONLY* context. This is normally done by passing a specially crafted array to eglCreateContext() as last argument. This is done after asking for an OpenGL ES 3.x context when choosing a configuration. Roughly, this can be done like this :
  

Code:

    const EGLint attribs[] = {
      EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
      EGL_BLUE_SIZE, 8,
      EGL_GREEN_SIZE, 8,
      EGL_RED_SIZE, 8,
      EGL_CONFORMANT, EGL_OPENGL_ES3_BIT_KHR,
      EGL_NONE
    };

    const EGLint GiveMeGLES3[] = {
      EGL_CONTEXT_MAJOR_VERSION_KHR, 3, EGL_CONTEXT_MINOR_VERSION_KHR, 1, EGL_NONE,
      EGL_NONE
    };

    /* ... */

    eglChooseConfig(display, attribs, &config, 1, &numConfigs);

    eglGetConfigAttrib(display, config, EGL_NATIVE_VISUAL_ID, &format);

    surface = eglCreateWindowSurface(display, config, window, NULL);
    context = eglCreateContext(display, config, NULL, GiveMeGLES3);

• Another issue is to ensure that you swap the buffers correctly after each frame. So, if the EGL context is properly setup but you still see nothing on the window, make sure that the swapping is done correctly.
  

Now, I highly recommend using something like https://github.com/apitrace/apitrace . Compile it for the test machine and for the debugging machine. On the test machine, you can run it like that :

Code:

apitrace trace -a egl -o /tmp/output.trace ./YourBinaryName -your arguments

And then, on the debugging machine, transfer /tmp/output.trace and use qapitrace to read it, either from the qapitrace 'File → Open' menu or by typing :

Code:

qapitrace output.trace

There you should have a trace of ALL the EGL and OpenGL calls that were executed by your software. Double clicking on a traced call will replay all everything up to this call on the debugging machine and tell you if there were some errors at some point.

Still, remember that, in the OpenGL world printf logs will generally be the only tools you can rely on for live debugging. GDB can help you look at the CPU buffers content, but no the GPU ones and can't help you detect OpenGL specific issues.

---

I currently host a simple OpenGL 3.1 example here :
https://github.com/Miouyouyou/MyyOpenGLH...mple-cmake

You can browse the code. The whole EGL initialisation is done using these two parts of code :
https://github.com/Miouyouyou/MyyOpenGLH...t/opengl.h
https://github.com/Miouyouyou/MyyOpenGLH...dow.c#L173

[phoenix]

OpenGL issues are very hard to pinpoint. It could be due to many things but one of the most common issue is that the EGL context was not properly setup. Setting up the context can be quite a pain, and doing it wrong will generally lead to several issues like no Depth Testing, for example.

Try to abuse eglGetError, in order to pinpoint the issue. Some frameworks having macros like CHECK_EGL(egl_instruction(params)) that expand to a few log calls using the value of eglGetError() after executing the instruction.

The major pitfalls are :

• Forgetting to ask for an OpenGL ES 3.0 or 3.1 *ONLY* context. This is normally done by passing a specially crafted array to eglCreateContext() as last argument. This is done after asking for an OpenGL ES 3.x context when choosing a configuration. Roughly, this can be done like this :
  

Code:

    const EGLint attribs[] = {
      EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
      EGL_BLUE_SIZE, 8,
      EGL_GREEN_SIZE, 8,
      EGL_RED_SIZE, 8,
      EGL_CONFORMANT, EGL_OPENGL_ES3_BIT_KHR,
      EGL_NONE
    };

    const EGLint GiveMeGLES3[] = {
      EGL_CONTEXT_MAJOR_VERSION_KHR, 3, EGL_CONTEXT_MINOR_VERSION_KHR, 1, EGL_NONE,
      EGL_NONE
    };

    /* ... */

    eglChooseConfig(display, attribs, &config, 1, &numConfigs);

    eglGetConfigAttrib(display, config, EGL_NATIVE_VISUAL_ID, &format);

    surface = eglCreateWindowSurface(display, config, window, NULL);
    context = eglCreateContext(display, config, NULL, GiveMeGLES3);

• Another issue is to ensure that you swap the buffers correctly after each frame. So, if the EGL context is properly setup but you still see nothing on the window, make sure that the swapping is done correctly.
  

Now, I highly recommend using something like https://github.com/apitrace/apitrace . Compile it for the test machine and for the debugging machine. On the test machine, you can run it like that :

Code:

apitrace trace -a egl -o /tmp/output.trace ./YourBinaryName -your arguments

And then, on the debugging machine, transfer /tmp/output.trace and use qapitrace to read it, either from the qapitrace 'File → Open' menu or by typing :

Code:

qapitrace output.trace

There you should have a trace of ALL the EGL and OpenGL calls that were executed by your software. Double clicking on a traced call will replay all everything up to this call on the debugging machine and tell you if there were some errors at some point.

Still, remember that, in the OpenGL world printf logs will generally be the only tools you can rely on for live debugging. GDB can help you look at the CPU buffers content, but no the GPU ones and can't help you detect OpenGL specific issues.

---

I currently host a simple OpenGL 3.1 example here :
https://github.com/Miouyouyou/MyyOpenGLH...mple-cmake

You can browse the code. The whole EGL initialisation is done using these two parts of code :
https://github.com/Miouyouyou/MyyOpenGLH...t/opengl.h
https://github.com/Miouyouyou/MyyOpenGLH...dow.c#L173

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);
}
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);

pEGLDisplay = eglGetDisplay( pX11Display);
printf("EGL Display pointer 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);


-----------------------
I never reach the "Success" , According to khronos , there is no need for a window to be created and nothing else but a supporting display to initialize EGL
the link is
https://www.khronos.org/registry/EGL/ext...rm_x11.txt

before everything even begins , Khronos calls the get_display() function , which doesn't even require a running window. just a display.
I get the display, I get the EGLDisplay , yet the EGLinit fails constantly with a return of 0x3001 , which means EGL_NOT_INITIALIZED , telling me the display can't be initialized. This is the same, of course, using your sample programs as well.


Any thoughts ?
Thank you .

[Myy]

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