The hardware platform is x86 Linux server+T4 card, the operating system is Centos 7.6, the driver version is 418.67, and the cuda version is 10.1. Use “glxinfo | grep OpenGL” tool to check that the OpenGL version is 2.1. How do I upgrade OpenGL version to 4.5 or 4.6 without changing the driver version?
I have executed the “yum install mesa *” operation, but the OpenGL version remains unchanged.
Hi there @1121320004 and welcome to the NIVIDIA developer forums.
The implementation of core OpenGL functionality is part of the GPU driver if you want to make full use of the installed Hardware. That means the OGL API implementation is an inherent part of the driver. But you should be able to still upgrade for your T4, the recommended driver version is 460.106 on Linux 64bit and the driver already supports OpenGL 4.6 as stated in the release notes.
I hope that helps!
Thank you very much for your reply. There is still a problem.
There are currently two servers with driver versions of 418.67. One of them has an OpenGL version of 4.6, but the other is 2.1. I would like to know how to upgrade an OpenGL version of 2.1 to 4.6.
Hello again.
There is no safe way to install a different OpenGL version supported by an NVIDIA GPU on a Linux machine without also installing the relevant driver.
For example the driver you listed, 418.67, will have support for OpenGL 4.5 if it is properly installed. Not 4.6 and not 2.1.
I highly recommend that you cleanly re-install the latest recommended driver 460.106. That way you will get OpenGL 4.6 as well.
However, the project requires that the driver version of 418.67 be used, and the driver version cannot be upgraded.
I downloaded the “418.67.run” file from the official website.
execute “./NVIDIA-Linux-x86_64-418.67.*.run”.
After the installation is complete, execute “glxinfo | grep OpenGL”, and the resulting OpenGL version is 2.1. I don’t know what’s wrong with my operation, can you tell me?
Please read this post:
and then share the nvidia-bug-report.log.gz file here.
I suspect you have an older installation left on your device. Ideally you would start with a fresh OS installation before installing the GPU driver.
nvidia-bug-report.log (2.2 MB)
This is the log information to help locate the problem.
It seems you have a bunch of T4 cards here as I see NVLINK being initialized. And I see 5 different driver versions:
3月 09 16:12:29 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 239
3月 09 16:12:29 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 515.86.01 Wed Oct 26 09:12:38 UTC 2022
3月 09 16:12:44 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 16:12:44 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 515.86.01 Wed Oct 26 09:12:38 UTC 2022
3月 09 16:12:44 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 515.86.01 Wed Oct 26 09:02:01 UTC 2022
3月 09 19:37:03 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 19:37:03 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 418.226.00 Wed Sep 8 13:57:02 UTC 2021
3月 09 19:37:12 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 19:37:12 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 418.226.00 Wed Sep 8 13:57:02 UTC 2021
3月 09 19:37:12 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 418.226.00 Wed Sep 8 13:44:34 UTC 2021
3月 09 19:40:02 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 239
3月 09 19:40:02 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 450.216.04 Wed Oct 5 04:59:55 UTC 2022
3月 09 19:40:10 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 239
3月 09 19:40:10 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 450.216.04 Wed Oct 5 04:59:55 UTC 2022
3月 09 19:40:10 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 450.216.04 Wed Oct 5 04:53:58 UTC 2022
3月 09 19:43:47 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 239
3月 09 19:43:47 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 470.161.03 Wed Oct 19 00:10:36 UTC 2022
3月 09 19:43:47 localhost.localdomain kernel: nvidia-uvm: Loaded the UVM driver, major device number 237.
3月 09 19:43:47 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 470.161.03 Wed Oct 19 00:05:15 UTC 2022
3月 09 19:44:00 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 19:44:00 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 470.161.03 Wed Oct 19 00:10:36 UTC 2022
3月 09 19:44:00 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 470.161.03 Wed Oct 19 00:05:15 UTC 2022
3月 09 19:46:18 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 19:46:18 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 418.67 Sat Apr 6 03:07:24 CDT 2019
3月 09 19:46:18 localhost.localdomain kernel: nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 238
3月 09 19:46:18 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 418.67 Sat Apr 6 02:43:09 CDT 2019
3月 09 19:46:25 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 240
3月 09 19:46:25 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 418.67 Sat Apr 6 03:07:24 CDT 2019
3月 09 19:46:25 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 418.67 Sat Apr 6 02:43:09 CDT 2019
3月 09 20:13:27 localhost.localdomain kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 239
3月 09 20:13:27 localhost.localdomain kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 515.86.01 Wed Oct 26 09:12:38 UTC 2022
3月 09 20:13:27 localhost.localdomain kernel: nvidia-uvm: Loaded the UVM driver, major device number 237.
3月 09 20:13:27 localhost.localdomain kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 515.86.01 Wed Oct 26 09:02:01 UTC 2022
I have no idea what kind of system you are driving here, but to me it seems the mismatch of OpenGL versions is the least of your problems.
T4 is a GPU designed for data-center usage and installation in a Server environment. I think you should work with your OEM or Service provider to get a fresh installation and see if that solves your issues.
A few days ago, I uninstalled the 418.67 version of the driver and tried to install a driver that is>418.67. The OpenGL version has not been upgraded. The driver version is now restored to 418.67. As shown in the following figure.
version.bmp (1.2 MB)
My question is as follows:
There are two servers with the operating system Centos 7.6, driver versions 418.67, and cuda 10.1. The OpenGL versions printed through the previous code are 4.6 and 2.1, respectively. Higher versions of OpenGL render a frame with better performance than lower versions of OpenGL. It is suspected that different OpenGL versions lead to different performance. So I want to upgrade OpenGL with the same driver version.
Once, I installed a 515.86 driver and displayed the OpenGL version as 4.6 through “glxinfo | grep OpenGL”. However, I added “const GLubyte * version=glGetString (GL_VERSION); printf (” version is% s “, version);” to my code and the printed version was 2.1. Running the same program to render a frame did not improve performance.
Please share the output of glxinfo here, maybe that will tell us something.
You mentioned you installed Mesa? Please remove that again, it can conflict with NVIDIA drivers. Also check if by any chance you have the environment variable MESA_GL_VERSION_OVERRIDE set to the older value.
For some reason you have an old version of an OpenGL library installed and you need to remove that before installing a new one. Which one that is and where it might reside is really difficult to diagnose remotely.
After executing glxinfo, I found “direct Rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)”.
Then I added the environment variable “export LIBGL_DEBUG=verbose”. Execute glxinfo again, and the result is the same.
And I also executed LIBGL_ DEBUG=verbose, and then executing glxinfo results in the same way.The specific information is as follows:
glxinfo_GLDebug.txt (32.9 KB)
In what form do libraries that affect OpenGL versions exist? . so or something else?
I printed the environment variable MESA_ GL_ VERSION_ OVERRIDE, the output is empty. This is the result for several servers on my side(including high version of OpenGL).
As I suspected:
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)
One way to check which OGL libraries are uses would be
ldconfig -p | grep GL
and see where the sym links point to. Another thing to consider is whether you are using the machines directly or remotely. If it is a remote server you are probably not running an actual XServer and thus the NVIDIA GPU might not be set up for rendering.
I would recommend comparing the working server setup and the non-working closely with respect to installed packages (your CentOS packaging manager will help you find them out) as well as sym links of the relevant GL libraries.