Unable to Create OpenGL Contexts on the Nano

[thompsonnoah]

Hello,

I’m attempting to learn OpenGL on the Jetson Nano, following this tutorial. I’ve installed the latest versions of GLFW and GLEW. I also have a PuTTY session connected to my Nano running an X server on localhost:10.0, with X11 forwarding enabled. My DISPLAY variable is set to localhost:10.0. Currently, I’m running into an issue where the program will exit with an error code stating the following:

EGL: Failed to get EGL display: Success

If I change GLFW_EGL_CONTEXT_API to GLFW_NATIVE_CONTEXT_API, I get the following:

GLX: GLX version 1.3 is required

Below is my sample program:

#include <iostream>
#include <GL/glew.h>
#include <GLFW/glfw3.h>

int main() {
    glfwInit();
    glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_ES_API);
    glfwWindowHint(GLFW_CONTEXT_CREATION_API, GLFW_EGL_CONTEXT_API);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);

    glfwSetErrorCallback([](int, const char* err_str) {
        std::cout << err_str << std::endl;
    });



    GLFWwindow* window = glfwCreateWindow(800, 600, "LearnOpenGL", nullptr, nullptr);
    if (window == nullptr)
    {
        std::cout << "Failed to create GLFW window" << std::endl;
        glfwTerminate();
        return -1;
    }
    glfwMakeContextCurrent(window);

    glViewport(0, 0, 800, 600);

    auto status = glewInit();
    std::cout << (status == GLEW_OK ? glewGetString(GLEW_VERSION) : glewGetErrorString(GLEW_VERSION)) << std::endl;


    while(!glfwWindowShouldClose(window))
    {
        glfwSwapBuffers(window);
        glfwPollEvents();
    }

    glfwTerminate();

    return 0;
}

What I want is to open a blank window that I can render content on. Any assistance is greatly appreciated.

Kind regards,

Noah

[DaneLLL]

Hi,
We would suggest begin with the samples in

/usr/src/nvidia/graphics_demos

The samples can be run by default. You can try to run the samples first and then look into the code.

[thompsonnoah]

@DaneLLL

/usr/src/nvidia/graphics_demos

Hi DaneLLL,

Thanks for your quick reply! I attempted to run some of the sample apps (the prebuilt binaries in /usr/src/nvidia/graphics_demos/prebuilts/bin/x11), and I got this error, very similar to what I got earlier:

EGL failed to obtain display.

I’m also uncertain if these samples apps include GLFW, at first glance it doesn’t appear that they do. Is there any known usage of GLFW on the Nano that I can look at?

[linuxdev]

Are you running this directly in the GUI environment? Is there anything special, e.g., remote SSH launch or VNC? Do you see anything from “echo $DISPLAY”? That’s the basic requirement to find a display.

[thompsonnoah]

Hi @linuxdev,

I’m running the test app from my laptop which is connected to the Nano over SSH via PuTTY. echo $DISPLAY outputs this:

localhost:10.0

[linuxdev]

That means OpenGL is not running on the Jetson. The missing requirements are on the PC which is performing the display. The gist is that when you run a command on a remote Linux system, and display it to the local PC, that the display code is being forwarded to the PC, and the GPU of the Jetson is not even used. The exception is if you have a virtual display environment the GPU of the Jetson is used for at least part of this, but then the display on your PC would also have to support OpenGL of the correct release version.

Without forwarding or virtual desktop X events are generated which are interpreted at the Jetson’s local GPU and displayed to its monitor (you would have to have a monitor running on the Jetson for this to work).

SSH forwarding can be used, although it probably is not what you really want. To start an ssh session from PC to Jetson with forwarding, you’d use either “ssh -Y ...login credentials...” or “ssh -X ...login credentials...”. The “-Y” and “-X” are two forms of forwarding X events from the Jetson to the PC. The events are then turned into graphics commands at the PC. For this you would not need a monitor on the Jetson, and all graphics work is on the PC.

A virtual desktop is sort of a hybrid. A local monitor is essentially a GPU buffer shared with a monitor, and as the buffer updates, the monitor sees the results. The X server does not really care if the buffer is visible to the monitor or not, so if it is just a buffer without a monitor, then computation will work just fine (only you won’t have a display). If you write a second program which reads that buffer and is connected to an actual display, then that second program reads an exact bitmap from the original buffer and displays it on some other monitor (which might or might not itself use OpenGL). The Jetson would not care, and the program monitoring that buffer could also be on the Jetson, but more likely it is on a remote PC. The use of the Jetson’s GPU for CUDA would occur on the Jetson, and OpenGL would also talk to that buffer, and the monitor used to look at the buffer from some remote location would have its own separate requirements which the program on the Jetson would neither see nor care about (the remote VNC monitor could be purely software and slow, or it could be hardware accelerated and fast, but the computation at the PC would be independent of the computation on the Jetson).

Do you want the CUDA and similar software to run on the Jetson, but display on a remote system? Or are you ok with all of the graphics and GPU activity being forwarded to the host PC? To start ssh for display on a PC and not caring about the PC taking over the work (I’m pretending your account is “loginname” and the IP address is 192.168.55.1):
ssh -Y loginname@192.168.55.1

Installing a virtual desktop is a much more complicated step.

[thompsonnoah]

Hi again @linuxdev,

I was actually able to resolve this issue on my own. The problem was that Xming’s GLX version is 1.2, whereas GLFW requires a minimum version of 1.3. I switched over to MobaXTerm, which has a GLX version of 1.4. The Nano supports GLX 1.4 as well, so I am able to use GLFW_NATIVE_CONTEXT_API as the API for creating the context.

TL:DR: Use MobaXTerm over XMing when using GLFW.