Usage on Raspberry Pi 4

[doodlewind]

Hi, Glitter works great, thanks for your work!

I'm trying to run this project on a Raspberry Pi 4 with the default Raspbian OS installed. An additional trick is supposed to make it work:

sudo apt-get install libxinerama-dev libxcursor-dev libxi-dev 

Then the project should compile successfully (with quite a long time). However the Glitter binary still can't bring up the GL context:

➜  Build git:(master) ./Glitter/Glitter
Failed to Create OpenGL Context%

Guess that we should use OpenGL ES instead of OpenGL. Any advice? Thanks!

[doodlewind]

Seems that the glfwWindowHint is misleading on GLES devices. This should work:

    glfwInit();
    // glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
    // glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
    // glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
    // glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
    // glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
    auto mWindow = glfwCreateWindow(mWidth, mHeight, "OpenGL", nullptr, nullptr);

Can we remove these glfwWindowHint for better compatibility for ARM desktop devices like Raspberry Pi? Thanks.

[Polytonic]

Mmm, I don't actually have an ARM device to test on. Probably unlikely that I remove what I have now, as they are somewhat sane defaults, but I can leave this open here for now at least? Or would adding in a comment blurb help at all instead?

[AlexApps99]

https://www.raspberrypi.org/forums/viewtopic.php?t=192017 says the following:

The Pi firmware (binary blob) supports OpenGLES only. It also has a composition API called DispmanX.
There is an open Linux kernel OpenGL and KMS (composition) driver actively under development.

The OpenGL side can be used either with the kernel KMS driver ("full kms"), or retaining the DispmanX API for composition ("fake KMS"). There are numerous things that can only sensibly be used with the "fake KMS" driver, eg video playback and the camera, as in both cases they directly send images to the composition engine/screen rather than going via the kernel.

It seems to use OpenGL on the Raspberry Pi efficiently fake KMS needs to be enabled.
To do this simply run sudo raspi-config, then select Advanced Options > GL Driver > GL (Fake KMS).

[RickyC0626]

Seems that the glfwWindowHint is misleading on GLES devices. This should work:

    glfwInit();
    // glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
    // glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
    // glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
    // glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
    // glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
    auto mWindow = glfwCreateWindow(mWidth, mHeight, "OpenGL", nullptr, nullptr);

Can we remove these glfwWindowHint for better compatibility for ARM desktop devices like Raspberry Pi? Thanks.

These window hints were causing problems as well on Windows 10 WSL 2. Removing them did the trick, plus it provides backwards-compatibility out of the box with devices that have max compatible profile versions for OpenGL 3.3 and below.

[chrisRidgers]

I've been running into this friction on WSL as well.

I believe its because in WSL/docker it doesn't have access to your graphics card. Getting the learnopengl.com tutorials running is possible but performance is not great and when you get to model loading you'll notice a real slow down (and im running on an a ryzen 7 5800x CPU, I suspect your pi device will have worse performance again).

For context, maybe worth its own ticket:

There's some articles around Windows WSL and Docker getting graphics card access in an upcoming build (Windows 11, build 22000?)

https://developer.nvidia.com/cuda/wsl
https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps

But I've just attempted to cmake from WSL inside windows11 and ran into errors regarding missing X11 window stuff:

cmake ..
-- Using X11 for window creation
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)

Which might be to do with this repo specifically? As part of its cmake configuration? Presumably if WSL can now throw up a window then cmake shouldn't need to check that X11 is available. Maybe its too much of an edge case.

[Polytonic]

I don't have a Win11 compatible machine yet (stuck on a 6700K due to chip shortage) so unfortunately I can't help repro that just yet.

If the window hints are problematic, I'm not above removing them, though they are useful for older compat reasons. I am hesitant to support dual OpenGL 4xx + GLES stacks though.

[chrisRidgers]

Yeh no worries, I only mentioned it here because I got it working on Windows 10 w/ what i think are limited grahpics not from my card, and I think the performance I got out of the tutorial code will be comparable to the Pi devices performance.

I've created a spearate issue for WSL2 specifically.