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;
glGetIntegerv(GL_MAJOR_VERSION, &glmajor);
glGetIntegerv(GL_MINOR_VERSION, &glminor);
std::cout << "GL major = " << glmajor << " minor = " << glminor << std::endl;
GLuint handle;
glGenTextures(1, &handle);
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).
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”).
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.
@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.
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.