Finding OpenGL ES 2.0 Mesa 18.3.4 on RHEL 7 for MFIX

RobbieTheK · March 5, 2022, 2:51am

We use RHEL 7.5 and trying to get MFiX to run via ssh -X or -Y.

We got it working on Windows with MobaXterm.

I’ve tried several ways with XQuartz and all the suggested work arounds

OpenGL rendering with X11 forwarding (stackexchange)

I found. I posted on the MFiX forum

Mfix-21.4 & RHEL 7.5 with X11 starts and fails to open GLEW could not be initialized: Missing GL version

but the maintainer there says this isn’t a issue with MFiX and it’s an OS/dependency problem and suggested I post here. Only the -k option runs on a Mac.

On a whim, I decided to run yum update and lo and behold I could open 3d viz with MFiX just on MobaXterm. What I noticed was this now appears from glxinfo | grep OpenGL:

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.4

Does anyone know which package and/or update this may have come from? Before the yum update it was:

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)

Dark_Photon · March 5, 2022, 1:25pm

RobbieTheK:

On a whim, I decided to run yum update and lo and behold I could open 3d viz with MFiX just on MobaXterm.

What I noticed was this now appears from glxinfo | grep OpenGL:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.4
Does anyone know which package and/or update this may have come from? Before the yum update it was:
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)

Ok, so in brief (and reading between the lines), it sounds like you were/are trying to throw the graphics window output…:

FROM a Linux, OpenGL, and X/Windows-based CFD compute+vis app (MFiX)
ONTO the display of a remote system running Windows or Mac, using MobaXterm and XQuartz, respectively,
USING ssh X11 display forwarding.

Am I even close?

And you did a package update on the RHEL 7.5 system running MFiX, and “things changed”. It now displays on Windows/MobaXterm but not Mac/XQuartz. Right?

Well among other things probably, it looks like you pulled in an update to your Mesa3D libraries (from ver 10.5.4 to ver 18.3.4). To see which Mesa3D packages you currently have installed, run the following command. I think you’ll find that most of them now have an 18.3.4 in the package name:

rpm -qa | grep -i mesa | sort

Mesa3D provides low-level OpenGL rendering capability via a software renderer and GPU hardware-accelerated renderers. Which path is used depends on your GPU+config. In your system’s state prior to the package update, it looks like you were using the software (CPU) based renderer.

BTW, for the benefit of other readers, I’ve link’ified your post and adjusted the formatting. I couldn’t make heads-or-tails of what you were talking about until I followed the links and inferred some things. And sorry about not being able to post links. This is new user spam avoidance. Keep reading+posting and you’ll be able to post links soon.

Dark_Photon · March 5, 2022, 2:00pm

From your post to the MFiX forum:

Mfix-21.4 & RHEL 7.5 with X11 starts and fails to open GLEW could not be initialized: Missing GL version

you say that, after doing a full-system package update, you’re getting these errors now when trying to display the MFiX window output on Mac/XQuartz via SSH X11 forwarding:

libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

These are associated with the Mesa3D software OpenGL rasterizer.

I don’t run Redhat, but here on a different Linux distro, these are provided in the Mesa-dri package:

> rpm -qf /usr/lib64/dri/swrast_dri.so
Mesa-dri-18.0.2-lp150.18.3.1.x86_64

So you could check the RHEL 7.5 packages available and see if you don’t have one of the Mesa3D library packages installed. It might be one with dri in the name that you’re missing.

RobbieTheK · March 5, 2022, 4:01pm

Spot on.

Correct.

On a working now after yum update we have:

rpm -qa | grep -i mesa | sort
mesa-demos-8.3.0-10.el7.x86_64
mesa-dri-drivers-18.3.4-12.el7_9.x86_64
mesa-filesystem-18.3.4-12.el7_9.x86_64
mesa-khr-devel-18.3.4-12.el7_9.x86_64
mesa-libEGL-18.3.4-12.el7_9.x86_64
mesa-libEGL-devel-18.3.4-12.el7_9.x86_64
mesa-libgbm-18.3.4-12.el7_9.x86_64
mesa-libgbm-devel-18.3.4-12.el7_9.x86_64
mesa-libGL-18.3.4-12.el7_9.x86_64
mesa-libglapi-18.3.4-12.el7_9.x86_64
mesa-libGL-devel-18.3.4-12.el7_9.x86_64
mesa-libGLES-18.3.4-12.el7_9.x86_64
mesa-libGLES-devel-18.3.4-12.el7_9.x86_64
mesa-libGLU-9.0.0-4.el7.x86_64
mesa-libGLU-devel-9.0.0-4.el7.x86_64
mesa-libGLw-8.0.0-5.el7.x86_64
mesa-libGLw-devel-8.0.0-5.el7.x86_64
mesa-libOSMesa-18.3.4-12.el7_9.x86_64
mesa-libOSMesa-devel-18.3.4-12.el7_9.x86_64
mesa-libxatracker-18.3.4-12.el7_9.x86_64
mesa-libxatracker-devel-18.3.4-12.el7_9.x86_64
mesa-private-llvm-3.9.1-3.el7.x86_64
mesa-private-llvm-devel-3.9.1-3.el7.x86_64
mesa-vdpau-drivers-18.3.4-12.el7_9.x86_64
mesa-vulkan-drivers-18.3.4-12.el7_9.x86_64

On a non-working node:

rpm -qa | grep -i mesa | sort
mesa-khr-devel-18.3.4-7.el7.x86_64
mesa-libEGL-18.3.4-7.el7.x86_64
mesa-libEGL-devel-18.3.4-7.el7.x86_64
mesa-libgbm-18.3.4-7.el7.x86_64
mesa-libGL-18.3.4-7.el7.x86_64
mesa-libglapi-18.3.4-7.el7.x86_64
mesa-libGL-devel-18.3.4-7.el7.x86_64
mesa-libGLU-9.0.0-4.el7.x86_64
mesa-libGLU-devel-9.0.0-4.el7.x86_64
mesa-libOSMesa-18.3.4-7.el7.x86_64
mesa-libwayland-egl-17.2.3-8.20171019.el7.x86_64

Prior to yum update I did run sudo yum install -y mesa-dri-drivers

rpm -qf /usr/lib64/dri/swrast_dri.so
mesa-dri-drivers-18.3.4-12.el7_9.x86_64

So I’m not sure if it was the yum update or running yum update after installing mesa-dri-drivers.

Thanks, I appreciate it I included the links as the other posts have more details and I’m grateful you took the time to put the pieces alltogether.

RobbieTheK · March 5, 2022, 5:16pm

I’m getting closer to determining which updates are needed. First I installed mesa-dri-drivers, then yum update mesa-*. But that wasn’t enough. In order to get mfix to open on the other nodes I also have to preface with the following:

MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 mfix

However I get this error:

libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

2022-03-05 11:57:07.455 (  32.108s) 
   [        AAAEEEC0]
   vtkOpenGLRenderWindow.c:499
   ERR| vtkXOpenGLRenderWindow (0x55555cf5c1f0): Unable to find a valid OpenGL 3.2 or later implementation. Please
   update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or
   later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and
   using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other
   remoting software such as nomachine to avoid this issue.

Segmentation fault

I also updated all xorg and X11 packages. Still a seg fault. What other package(s) need updating? The only llvm-related package that is the same on a working and non-working node, which I see came from mesa-dri-drivers, is

rpm -qa | grep -i llvm
llvm-private-7.0.1-1.el7.x86_64

Dark_Photon · March 6, 2022, 1:57am

I’m assuming you do want to run the software rasterizer, yes?

A few things to try that may give you some ideas:

Run this and then retry running mfix:
```
export LIBGL_DEBUG=verbose 
```
Do glxinfo and glxgears run properly?
Double check that the architecture of the mfix executable is 64-bit: via file mfix
Do an ldd mfix and see what dynamic libs it’s linked with at compile time.
Do an strace mfix 2>&1 | grep '\.so' and see what shared libs it’s trying to pull in dynamically at runtime?
Also, did you have the NVIDIA graphics drivers installed before the update? Did/could the update include a kernel update? If so, then you may need to reinstall the NVIDIA graphics drivers.

RobbieTheK · March 6, 2022, 4:17pm

Yes

OK that helped point me in the right direction.

First I installed mesa-dri-drivers. Then I updated libdrm and mesa-*. The libdrm update is what provided this output:

glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)
OpenGL version string: 2.1 Mesa 18.3.4
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

So now it works on Mobaxterm and Windows. However Mac/XQuartz still fails with:

AAAEEEC0]vtkOpenGLRenderWindow.c:493 ERR| vtkXOpenGLRenderWindow (0x55555cfa8b10): GLEW could not be initialized: Missing GL version

and glxinfo fails with:

name of display: localhost:10.0
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  31
  Current serial number in output stream:  30

So is there any way to get this working from a Mac and XQuartz or an alternative to XQuartz?

RobbieTheK · March 8, 2022, 5:18pm

A little update from a Mac/XQuartz.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
2022-03-08 11:16:21.992 (  13.944s) [        AAAEEEC0]vtkOpenGLRenderWindow.c:499    ERR| vtkXOpenGLRenderWindow (0x55555cfc32c0): Unable to find a valid OpenGL 3.2 or later implementation. Please update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other remoting software such as nomachine to avoid this issue.

glxinfo runs with these logs:

glxinfo
name of display: localhost:10.0
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
display: localhost:10  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: AMD Radeon Pro 5300M OpenGL Engine
OpenGL version string: 1.4 (2.1 ATI-4.7.103)

Any other suggestions?