I created a simple test program using the first code example in https://devblogs.nvidia.com/parallelforall/egl-eye-opengl-visualization-without-x-server/ . In the main function after the comment “// from now on use your OpenGL context”, I had added
GLuint glmajor, glminor;
std::cout << "GL major = " << glmajor << " minor = " << glminor << std::endl;
sd::cout << "handle = " << handle;
When running this on my Ubuntu 16.04 machine with an NVIDIA GTX 1080 and driver 384.90-0ubuntu0.16.04.1, the program displays glmajor 4 and glminor 5 and handle 1. After upgrading to driver 384.90-0ubuntu0.16.04.2, the program now displays glmajor 0 and glminor 0 and handle 0. It appears in the latter version that there is no active OpenGL context.
I think I’m having the same problem. I had working code based on the same link posted above, but after an update it no longer works. EGL does not generate any errors, but there is not a valid OpenGL context.
I’m running Ubuntu 16.04 with a GeForce GT 650M and driver 384.90 (though I don’t know how to get the exact version, as specified by OP).
To see what you have: apt list --installed | grep nvidia
On my machine, I get a line: nvidia-384/xenial-security, now 384.90-0ubuntu0.16.04.1 amd64 [installed,upgradable to 384.90-0ubuntu.16.04.2]
In order to have a working EGL environment, I had rolled back from the *.2 driver to the *.1 driver.
Can you please attach the complete source file so I can try to reproduce this problem?
This kind of sounds like a packaging problem rather than a problem with the driver itself. Does it work if you install the driver from the .run package? (Uninstall it when you’re done by running “sudo nvidia-uninstall”).
Thanks, I was using 384.90-0ubuntu0.16.04.2. After downgrading to *.1 my code works again.
It looks like there’s an open bug report on this issue: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+bug/1731968
@Aaron. Given the post about a bug already filed, please let me know whether you still want me to post the working test code. Thank you.
It looks like egl (+gl) works fine on latest 396 drives.
I still had problems with nvidia-396 but in a scenario specific to the product I worked on. Apparently, the 384.90-0ubuntu0.16.04.1 shipped with libglvnd as the default (unusual because other packages appear not to do this), in which case EGL worked. The *.2 package appeared not to have libglvnd as default. With nvidia-396, my Geometric Tools code worked fine with libGLX and libEGL, but the product I worked on did not. We tracked down the problem to GLFW loading libGL.so using dlload. Having libGLX, libGL and libEGL loaded in the same application led to the missing OpenGL context when using EGL. Our workaround was to use an OpenGL extension wrapper that allows you to select the function pointer lookup via GLX for visual applications or EGL for headless applications. I used my own wrapper for the run-time selection. GLEW appears to have you select either GLX or EGL via conditional compilation.
Yes, it is tricky to get it right, we also dynamically load all the libraries using the ‘glad2’ extension wrapper.
Here is a self-contained working example: https://github.com/erwincoumans/egl_example
@erwin Thanks for the working example. Has there been any update on this? The bug report is still open, and the minimal working example in that report still fails with the newest (396) nvidia drivers for me.
It turns out that this is likely an Ubuntu packaging issue (assuming you’re using Ubuntu) – EGL works on Arch and Fedora, and you can get it to work on Ubuntu if you install the drivers from a .run file rather than via apt.
I also have issues with using EGL on nvidia (https://devtalk.nvidia.com/default/topic/1037901/x11-with-egl-produces-black-window-for-driver-versions-gt-384). I am using the driver from the official nvidia CUDA repository for Ubuntu. If this is a packaging issue, could this issue be fixed for the official driver packages (on developer.download.nvidia.com) such that one can use the CUDA repository with automatic updates of the driver?
My understanding is that the CUDA packages are built the same way as the upstream packages. From this Launchpad bug, it sounds like they’ll be adding in support for GLES v1 in Bionic, so the CUDA packages should pick that up eventually.