AM625: OpenGLES/Vulkan perfomance drop after GUI libraries recompilation

Hello,

I have assigned your thread. Please expect delayed responses due to the holidays. Feel free to ping the thread if you do not get a reply within the first week of January.

Regards,

Nick

Hello,

What changes did you make because we are not officially supporting Vulkan and X. Are you observing performance drop with standard OpenGLES test? It would be helpful to understand your stack setup because there are a lot of layers in the GPU stack. I am not sure what you changed from standard SDK and it's performance impact. 

Regards,
Krunal

Hi Krunal,

Mesa utility program 'glxgears' shows 150 fps on OpenGL test. I still investigate conditions...

And, of course, huge modification was done to make system support all developer functionality (including documentation support).

Regards,

Alexey

'glxgears' is based on X Windows ecosystem, so OpenGLES in it goes through X-Server, which is different rendering environment.

Are you enabling Zink as well? 

Regards,
Krunal

HI Krunal,

Some programs like QT5 and GCC (with additional languages support) require some days to be compiled on this platform. I'm not ready to answer for this question yet.

Regards,

Alexey

Hi,

Herre what I get, when Zink is installed:

Successfully connected the Wayland display
Successfully retrieved the Wayland registry
Successfully retrieved the Wayland compositor
Successfully create the Wayland surface
Successfully create the Wayland shell surface
Host library 'libEGL.so' loaded
EGL Bindings: Successfully loaded library libEGL.so

WARNING: Some incorrect rendering might occur because the selected Vulkan device (PowerVR A-Series AXE-1-16M) doesn't support base Zink requirements: feats.features.fillModeNonSolid have_EXT_line_rasterization
Trying to create context for all configs.
Failed to create context for any configs. Tried 0 configs.
OpenGL ES 3.1 NOT supported. Trying lower version...
Trying to create context for all configs.
Failed to create context for any configs. Tried 0 configs.
OpenGL ES 3.0 NOT supported. Trying lower version...
Trying to create context for all configs.
EGL context creation: EGL_KHR_create_context supported

Regards,

Alexey

Hi,

I don't use any package manager yet. (Some specific configuration and relation to other programs is needed for many programs). All recompilations are native on a board. Hope, when everything works, I switch to package manager ecosystem to save time. Current TI SDK lacking some pkgconfig files and some headers, so recompilation is required. Even GCC requires Fortran support for specific programs. Not every program support wayland, so I added X11.

Hope I can understand how to restore links to proprietary GPU drivers.

Regards,

Alexey

Understood, thanks for the background. Keep me updated on your findings.

Regards,
Krunal

Hi,

My current X environment config setup is:

export GDK_BACKEND=wayland
export XDG_RUNTIME_DIR=/run/user/1000
export WAYLAND_DISPLAY=wayland-1
export DISPLAY=:1

These variables should be initialized each time bash session starts. X programs effectively start from Weston desktop itself using connected mouse and keyboard to SDK board (direct control of UI). XWayland installed module should also be enabled in Weston settings.

Regards,

Alexey

My current condition is:

am62xx-evm:~$ glxinfo -B
name of display: :0
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: zink
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa (0xffffffff)
    Device: llvmpipe (LLVM 17.0.6, 128 bits) (0xffffffff)
    Version: 24.0.0
    Accelerated: no
    Video memory: 1925MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 0 MB, largest block: 0 MB
    VBO free aux. memory - total: 1632 MB, largest block: 1632 MB
    Texture free memory - total: 0 MB, largest block: 0 MB
    Texture free aux. memory - total: 1632 MB, largest block: 1632 MB
    Renderbuffer free memory - total: 0 MB, largest block: 0 MB
    Renderbuffer free aux. memory - total: 1632 MB, largest block: 1632 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 881478 MB
    Total available memory: 883403 MB
    Currently available dedicated video memory: 0 MB
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 17.0.6, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 24.0.0
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.0.0
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

As you can see, there is no hardware acceleration for GLX graphical stack right now.

I just hope graphical layer will support GLX XWayland by the next Processor SDK release.

Regards,

Alexey

Hi Alexey,

At the moment, we are not planning on supporting GLX for current and next PSDK version. Once we migrate to the open source driver, the goal is to have X/GLX working because of Zink enablement. 

Regards,
Krunal

Hi Krunal,

Thanks for reply.

I saw info that TI's products based on IMG bxs-4-64-mc1 (as AM62P) natively support OpenGL stack. Does this mean, that such products will have GLX support in closer time?

Thanks...

Oh, sorry, my mistake. It was about OpenCL. So, no plans for that yet. At least there is a DirectFB solution for some scenarios, which I didn't tried yet.

Greetings,

The "libexoxy" library is completely unsupported in a way of using it in clean GLES2/3 environments, since it always require GL initialization functions, which are not supported in GLES. But this library is a key component in GNOME desktop environment. It is sad to know that this problem no one fixed since embedded Linux solutions become available.

Regards...

Is there no community support for it?

Regards,
Krunal

Actually, there is a GNOME Mutter window manager, which is true basic planform of GNOME UI, which claims to fully support OpenGLES environment. But for now, in practice, it is not fully conformant with OpenGLES+Gstreamer especially.

The main advantage of GNOME platform is UI abstraction layer, which gives making cross-platform application easier in a cost of higher memory consumption, of course.