Has anyone been able to get glfw running?

[Pablo Walters]

I'd like to use OpenGL under X windows.

[rpiMike]

Yes, just turn it on by using ‘sudo raspi-config’. Select Advanced Options, GL Driver, Full KMS. Then reboot.

[Pablo Walters]

That sounds great. I enabled GL Driver, Full KMS, and restarted.

Are there any simple examples that show how to compile a simple

c application using glfw on Raspberry PI?


I downloaded glfw from github and when I tried "cmake ." it failed with

a message that RandR headers were not found.

[rpiMike]

I googled this example:

https://www.badprog.com/c-opengl-hello-world

You will need to install the following library:

Code: Select all

sudo apt-get update
sudo apt-get install freeglut3-dev

Save the following code as main.cpp:

Code: Select all

#include <GL/glut.h>

void displayMe(void)
{
    glClear(GL_COLOR_BUFFER_BIT);
    glBegin(GL_POLYGON);
        glVertex3f(0.0, 0.0, 0.0);
        glVertex3f(0.5, 0.0, 0.0);
        glVertex3f(0.5, 0.5, 0.0);
        glVertex3f(0.0, 0.5, 0.0);
    glEnd();
    glFlush();
}

int main(int argc, char** argv)
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_SINGLE);
    glutInitWindowSize(300, 300);
    glutInitWindowPosition(100, 100);
    glutCreateWindow("Hello world :D");
    glutDisplayFunc(displayMe);
    glutMainLoop();
    return 0;
}

I had to compile with:

Code: Select all

g++ main.cpp -o lookAtThis -lglut -lGL

Then run:

Code: Select all

./lookAtThis

[Pablo Walters]

RaspPIglfw.JPG (68.11 KiB) Viewed 12833 times

I got glfw working on Raspberry PI using rpiMike's suggestion!


Here's the full sequence of things you have to do.

1. Select "GL Driver, Full KMS" by running raspi-config

sudo raspi-config

(Select Advanced Options, GL Driver, Full KMS. Then reboot)

2. download zip of glfw from github

https://github.com/glfw/glfw

3. install xorg-dev - this is required

sudo apt-get install xorg-dev

4. cd into the source directory and run cmake

cd glfw-3.2.1
cmake .

5. then run make

make

The examples and tests compile, and most things seem you be working,
although I do see this error message when an application starts:

libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

I think glfw is a very nice way to teach OpenGL ES on Raspberry PI since you can have the window
system running, etc.

[Pablo Walters]

FYI -

The source file glad.c in the GLFW distribution does not load functions to support VertexArrays,
Framebuffers and Renderbuffers, etc. I added a these to glad.c to make them work:

Code: Select all

diff glad.c.orig glad.c
1402a1403,1428
> 
> 	glad_glIsRenderbuffer = (PFNGLISRENDERBUFFERPROC)load("glIsRenderbuffer");
> 
> 	glad_glGenRenderbuffers = (PFNGLGENRENDERBUFFERSPROC)load("glGenRenderbuffers");
> 	glad_glBindRenderbuffer = (PFNGLBINDRENDERBUFFERPROC)load("glBindRenderbuffer");
> 	glad_glRenderbufferStorage = (PFNGLRENDERBUFFERSTORAGEPROC)load("glRenderbufferStorage");
> 
> 	glad_glGenFramebuffers = (PFNGLGENFRAMEBUFFERSPROC)load("glGenFramebuffers");
> 	glad_glBindFramebuffer = (PFNGLBINDFRAMEBUFFERPROC)load("glBindFramebuffer");
> 	glad_glFramebufferRenderbuffer = (PFNGLFRAMEBUFFERRENDERBUFFERPROC)load("glFramebufferRenderbuffer");
> 
> 	glad_glFramebufferTexture1D = (PFNGLFRAMEBUFFERTEXTURE1DPROC)load("glFramebufferTexture1D");
> 	glad_glFramebufferTexture2D = (PFNGLFRAMEBUFFERTEXTURE2DPROC)load("glFramebufferTexture2D");
> 	glad_glCheckFramebufferStatus = (PFNGLCHECKFRAMEBUFFERSTATUSPROC)load("glCheckFramebufferStatus");
> 	glad_glDeleteFramebuffers = (PFNGLDELETEFRAMEBUFFERSPROC)load("glDeleteFramebuffers");
> 
> 	glad_glDeleteRenderbuffers = (PFNGLDELETERENDERBUFFERSPROC)load("glDeleteRenderbuffers");
> 	glad_glGenVertexArrays = (PFNGLGENVERTEXARRAYSPROC)load("glGenVertexArrays");
> 	glad_glBindVertexArray = (PFNGLBINDVERTEXARRAYPROC)load("glBindVertexArray");
> 
> 	glad_glDeleteVertexArrays = (PFNGLDELETEVERTEXARRAYSPROC)load("glDeleteVertexArrays");
> 
> 	glad_glGetRenderbufferParameteriv = (PFNGLGETRENDERBUFFERPARAMETERIVPROC)load("glGetRenderbufferParameteriv");
> 	glad_glIsFramebuffer = (PFNGLISFRAMEBUFFERPROC)load("glIsFramebuffer");
> 	glad_glFramebufferTexture3D = (PFNGLFRAMEBUFFERTEXTURE3DPROC)load("glFramebufferTexture3D");
> 	glad_glGetFramebufferAttachmentParameteriv = (PFNGLGETFRAMEBUFFERATTACHMENTPARAMETERIVPROC)load("glGetFramebufferAttachmentParameteriv");

[ab1jx]

Is the glfw in the debs not worth bothering with?

glfw3.png (45.51 KiB) Viewed 8836 times

I'm just starting to learn OpenGL, but I know I really want GLES. So I'm reading the OpenGL redbook but taking it with a grain of salt. I don't really want software OpenGL but I suppose it would work to learn from. I just don't want things that conflict. I've heard I don't want to be using Mesa I think.

[ab1jx]

I googled this example:
...

Interesting. I just had it work even without the GL driver enabled in raspi-config.

Which seems to crash BTW. Once I enabled it and rebooted the machine seemed generally more sluggish. Then I tried to open a 4.3 meg JPEG I'd just taken in qiv and got booted out of X. Rebooted, same thing happened. Did startx, went into Gimp, loaded up the RAW version of the picture, made some edits, saved it out. Went back into raspi-config, turned off the GL driver, rebooted. qiv opens the same jpeg normally now. Fixed an error (my copying mistake]) in the GL example, compiled it. Decided to see what error message I got if the driver wasn't enabled, but there wasn't one, it just worked.

And i just did a screenshot using xwd and it shows it. If I try that with something like omxplayer there's just a black spot because xwd is an old program that works at an X level and omxplayer is at a lower level.

[Gavinmc42]

I use Gentoo64, the OpenGL driver seems more current and works better.
Had trouble under Raspbian

I started here
https://www.mesa3d.org/
Working my way through the demos.
https://www.mesa3d.org/repository.html

GLFW is a layer up?
It looks like it can do OpenGL, OpenGLES, and Vulkan.

Not sure, can it be used for baremetal or is x11 etc needed?

[ab1jx]

The stuff I'm interested in utilizing sits in /opt/vc and at least partly came from Broadcom:

Code: Select all

upstairs# dpkg-query -l | grep libraspberrypi
ii  libraspberrypi-bin                      1.20181112-1                                armhf        Miscellaneous Raspberry Pi utilities
ii  libraspberrypi-dev                      1.20181112-1                                armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers)
ii  libraspberrypi-doc                      1.20181112-1                                armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers)
ii  libraspberrypi0                         1.20181112-1                                armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV

I think the same thing is at https://github.com/raspberrypi/userland.

It comes with some common openGL demo programs that are also found elsewhere (but not optimized for this hardware). I just tried some without X, just the bare command line and some work. hello_videocube works normally, hello_teapot worked but without the overlay images. Hello_tiger worked but I think that's openVG. I wasn't taking notes, just trying to remember.

I tried the Gentoo image, and ran the 64 bit Debian Buster one for a few months, but came back to Raspbian for the Videocore stuff.

My goal isn't to draw pretty pictures but to make use of the GPU. Routines have been written for it to do FFT and SHA256 (possibly to mine Bitcoin with). There's an assembler at https://github.com/maazl/vc4asm/archive/master.zip, a gpu tools package at https://github.com/anholt/vc4-gpu-tools/ The GPU is powerful, maybe more so than the CPU, but it's weird. Look at some of Herman Hermitage's stuff.

In the interim I want to use GLES to do SDR (Software Defined Radio). I've seen it done (Peter Onion). If you try to do the display in X it's hard to get it efficient enough, you end up using CPU to make the display work, which cuts into using it for signal processing. I think you can plot data (several times per second) using vertex shaders.

Some of what this does is working into a framebuffer, I thought glfw was putting multiple framebuffer windows on the screen at once, which would be ideal, but now I don't think so. You can do fast graphics with a framebuffer but it's hard to make widgets for controls. Clustering widgets around a framebuffer window seems perfect.

/opt/vc/include on my Pi here looks like:

Code: Select all

total 40
-rw-r--r--  1 root root 2342 Feb  9  2018 bcm_host.h
drwxr-xr-x  2 root root 4096 Nov 20 18:02 EGL
drwxr-xr-x  2 root root 4096 Nov 20 18:02 GLES
drwxr-xr-x  2 root root 4096 Nov 20 18:02 GLES2
drwxr-xr-x  2 root root 4096 Nov 20 18:02 IL
drwxr-xr-x 10 root root 4096 Jul  2  2018 interface
drwxr-xr-x  2 root root 4096 Nov 20 18:02 KHR
drwxr-xr-x  2 root root 4096 Nov 20 18:02 vcinclude
drwxr-xr-x  2 root root 4096 Nov 20 18:02 VG
drwxr-xr-x  2 root root 4096 Nov 20 18:02 WF

./EGL:
total 56
-rw-r--r-- 1 root root  3988 Feb  9  2018 eglext_android.h
-rw-r--r-- 1 root root  8371 Feb  9  2018 eglext_brcm.h
-rw-r--r-- 1 root root  9044 Feb  9  2018 eglext.h
-rw-r--r-- 1 root root  2174 Feb  9  2018 eglext_nvidia.h
-rw-r--r-- 1 root root 12377 Feb  9  2018 egl.h
-rw-r--r-- 1 root root  7719 Feb  9  2018 eglplatform.h

./GLES:
total 96
-rw-r--r-- 1 root root 55912 Feb  9  2018 glext.h
-rw-r--r-- 1 root root 36087 Feb  9  2018 gl.h
-rw-r--r-- 1 root root  2505 Feb  9  2018 glplatform.h

./GLES2:
total 92
-rw-r--r-- 1 root root 52237 Feb  9  2018 gl2ext.h
-rw-r--r-- 1 root root 33485 Feb  9  2018 gl2.h
-rw-r--r-- 1 root root  2513 Feb  9  2018 gl2platform.h

./IL:
total 472
-rw-r--r-- 1 root root  82279 Feb  9  2018 OMX_Audio.h
-rw-r--r-- 1 root root 103360 Nov 12 12:25 OMX_Broadcom.h
-rw-r--r-- 1 root root  23869 Feb  9  2018 OMX_Component.h
-rw-r--r-- 1 root root  71220 Feb  9  2018 OMX_Core.h
-rw-r--r-- 1 root root   3229 Feb  9  2018 OMX_ILCS.h
-rw-r--r-- 1 root root  14684 Feb  9  2018 OMX_Image.h
-rw-r--r-- 1 root root  42246 Aug 17 11:25 OMX_Index.h
-rw-r--r-- 1 root root  37928 Mar 28  2018 OMX_IVCommon.h
-rw-r--r-- 1 root root  18255 Feb  9  2018 OMX_Other.h
-rw-r--r-- 1 root root  13146 Feb  9  2018 OMX_Types.h
-rw-r--r-- 1 root root  45522 Feb  9  2018 OMX_Video.h

./interface:
total 32
drwxr-xr-x 5 root root 4096 Nov 20 18:02 mmal
drwxr-xr-x 2 root root 4096 Nov 20 18:02 peer
drwxr-xr-x 5 root root 4096 Nov 20 18:02 vchi
drwxr-xr-x 2 root root 4096 Nov 20 18:02 vchiq_arm
drwxr-xr-x 5 root root 4096 Nov 20 18:02 vcos
drwxr-xr-x 2 root root 4096 Nov 20 18:02 vcsm
drwxr-xr-x 2 root root 4096 Nov 20 18:02 vctypes
drwxr-xr-x 4 root root 4096 Nov 20 18:02 vmcs_host

./interface/mmal:
total 236
drwxr-xr-x 2 root root  4096 Nov 20 18:02 core
-rw-r--r-- 1 root root 12773 Aug 17 11:25 mmal_buffer.h
-rw-r--r-- 1 root root  7417 Feb  9  2018 mmal_clock.h
-rw-r--r-- 1 root root  3136 Feb  9  2018 mmal_common.h
-rw-r--r-- 1 root root  5659 Feb  9  2018 mmal_component.h
-rw-r--r-- 1 root root 14157 Sep 11 05:35 mmal_encodings.h
-rw-r--r-- 1 root root  4614 Feb  9  2018 mmal_events.h
-rw-r--r-- 1 root root  9479 Feb  9  2018 mmal_format.h
-rw-r--r-- 1 root root 17927 Aug 17 11:25 mmal.h
-rw-r--r-- 1 root root  3640 Feb  9  2018 mmal_logging.h
-rw-r--r-- 1 root root  3127 Feb  9  2018 mmal_parameters_audio.h
-rw-r--r-- 1 root root 40231 Aug 17 11:25 mmal_parameters_camera.h
-rw-r--r-- 1 root root  3702 Feb  9  2018 mmal_parameters_clock.h
-rw-r--r-- 1 root root  8315 Feb  9  2018 mmal_parameters_common.h
-rw-r--r-- 1 root root  6430 Feb  9  2018 mmal_parameters.h
-rw-r--r-- 1 root root 23794 Nov 12 12:25 mmal_parameters_video.h
-rw-r--r-- 1 root root  7744 Feb  9  2018 mmal_pool.h
-rw-r--r-- 1 root root 12430 Feb  9  2018 mmal_port.h
-rw-r--r-- 1 root root  4178 Feb  9  2018 mmal_queue.h
-rw-r--r-- 1 root root  4053 Feb  9  2018 mmal_types.h
drwxr-xr-x 2 root root  4096 Nov 20 18:02 util
drwxr-xr-x 2 root root  4096 Nov 20 18:02 vc

./interface/mmal/core:
total 44
-rw-r--r-- 1 root root 4241 Feb  9  2018 mmal_buffer_private.h
-rw-r--r-- 1 root root 6850 Feb  9  2018 mmal_clock_private.h
-rw-r--r-- 1 root root 6905 Feb  9  2018 mmal_component_private.h
-rw-r--r-- 1 root root 1770 Feb  9  2018 mmal_core_private.h
-rw-r--r-- 1 root root 2740 Feb  9  2018 mmal_events_private.h
-rw-r--r-- 1 root root 9384 Feb  9  2018 mmal_port_private.h

./interface/mmal/util:
total 84
-rw-r--r-- 1 root root  6135 Feb  9  2018 mmal_component_wrapper.h
-rw-r--r-- 1 root root 11277 Sep 11 05:35 mmal_connection.h
-rw-r--r-- 1 root root  5048 Feb  9  2018 mmal_default_components.h
-rw-r--r-- 1 root root 11208 Feb  9  2018 mmal_graph.h
-rw-r--r-- 1 root root  8986 Aug 17 11:25 mmal_il.h
-rw-r--r-- 1 root root  4310 Feb  9  2018 mmal_list.h
-rw-r--r-- 1 root root  3243 Feb  9  2018 mmal_param_convert.h
-rw-r--r-- 1 root root  7243 Feb  9  2018 mmal_util.h
-rw-r--r-- 1 root root  7860 Feb  9  2018 mmal_util_params.h
-rw-r--r-- 1 root root  3927 Feb  9  2018 mmal_util_rational.h

./interface/mmal/vc:
total 52
-rw-r--r-- 1 root root  2185 Feb  9  2018 mmal_vc_api_drm.h
-rw-r--r-- 1 root root  8597 Feb  9  2018 mmal_vc_api.h
-rw-r--r-- 1 root root  3133 Feb  9  2018 mmal_vc_client_priv.h
-rw-r--r-- 1 root root  1710 Feb  9  2018 mmal_vc_msgnames.h
-rw-r--r-- 1 root root 17436 Feb  9  2018 mmal_vc_msgs.h
-rw-r--r-- 1 root root  2591 Feb  9  2018 mmal_vc_opaque_alloc.h
-rw-r--r-- 1 root root  2285 Feb  9  2018 mmal_vc_shm.h

./interface/peer:
total 4
-rw-r--r-- 1 root root 3098 Mar 28  2018 vc_vchi_dispmanx_common.h

./interface/vchi:
total 60
drwxr-xr-x 2 root root  4096 Nov 20 18:02 common
drwxr-xr-x 2 root root  4096 Nov 20 18:02 connections
drwxr-xr-x 2 root root  4096 Nov 20 18:02 message_drivers
-rw-r--r-- 1 root root  9283 Feb  9  2018 vchi_cfg.h
-rw-r--r-- 1 root root  2963 Feb  9  2018 vchi_cfg_internal.h
-rw-r--r-- 1 root root  6560 Feb  9  2018 vchi_common.h
-rw-r--r-- 1 root root 16498 Mar 13  2018 vchi.h
-rw-r--r-- 1 root root  1683 Feb  9  2018 vchi_mh.h

./interface/vchi/common:
total 4
-rw-r--r-- 1 root root 2114 Feb  9  2018 endian.h

./interface/vchi/connections:
total 16
-rw-r--r-- 1 root root 16215 Feb  9  2018 connection.h

./interface/vchi/message_drivers:
total 12
-rw-r--r-- 1 root root 8733 Feb  9  2018 message.h

./interface/vchiq_arm:
total 40
-rw-r--r-- 1 root root 2606 Feb  9  2018 vchiq_cfg.h
-rw-r--r-- 1 root root 1666 Feb  9  2018 vchiq.h
-rw-r--r-- 1 root root 7897 Mar 13  2018 vchiq_if.h
-rw-r--r-- 1 root root 4343 Feb  9  2018 vchiq_ioctl.h
-rw-r--r-- 1 root root 5130 Feb  9  2018 vchiq_test.h
-rw-r--r-- 1 root root 1676 Feb  9  2018 vchiq_test_if.h
-rw-r--r-- 1 root root 2289 Feb  9  2018 vchiq_util.h

./interface/vcos:
total 248
drwxr-xr-x 2 root root  4096 Nov 20 18:02 generic
drwxr-xr-x 2 root root  4096 Jul  2  2018 glibc
drwxr-xr-x 2 root root  4096 Nov 20 18:02 pthreads
-rw-r--r-- 1 root root  2190 Feb  9  2018 user_nodefs.h
-rw-r--r-- 1 root root  8955 Feb  9  2018 vcos_assert.h
-rw-r--r-- 1 root root  3046 Feb  9  2018 vcos_atomic_flags.h
-rw-r--r-- 1 root root  6244 Feb  9  2018 vcos_attr.h
-rw-r--r-- 1 root root  6308 Feb  9  2018 vcos_blockpool.h
-rw-r--r-- 1 root root  1705 Feb  9  2018 vcos_build_info.h
-rw-r--r-- 1 root root  4473 Feb  9  2018 vcos_cfg.h
-rw-r--r-- 1 root root  4488 Feb  9  2018 vcos_cmd.h
-rw-r--r-- 1 root root  1922 Feb  9  2018 vcos_ctype.h
-rw-r--r-- 1 root root  2917 Feb  9  2018 vcos_dlfcn.h
-rw-r--r-- 1 root root  4146 Feb  9  2018 vcos_event_flags.h
-rw-r--r-- 1 root root  3676 Feb  9  2018 vcos_event.h
-rw-r--r-- 1 root root  7315 Feb  9  2018 vcos.h
-rw-r--r-- 1 root root  4407 Feb  9  2018 vcos_init.h
-rw-r--r-- 1 root root  2047 Feb  9  2018 vcos_inttypes.h
-rw-r--r-- 1 root root  3257 Feb  9  2018 vcos_isr.h
-rw-r--r-- 1 root root  3874 Feb  9  2018 vcos_legacy_isr.h
-rw-r--r-- 1 root root  1534 Feb  9  2018 vcos_logging_control.h
-rw-r--r-- 1 root root 12659 Aug 17 11:25 vcos_logging.h
-rw-r--r-- 1 root root  5073 Feb  9  2018 vcos_lowlevel_thread.h
-rw-r--r-- 1 root root  3415 Feb  9  2018 vcos_mem.h
-rw-r--r-- 1 root root  3530 Feb  9  2018 vcos_mempool.h
-rw-r--r-- 1 root root  9536 Feb  9  2018 vcos_msgqueue.h
-rw-r--r-- 1 root root  3577 Feb  9  2018 vcos_mutex.h
-rw-r--r-- 1 root root  3752 Feb  9  2018 vcos_named_semaphore.h
-rw-r--r-- 1 root root  2256 Feb  9  2018 vcos_once.h
-rw-r--r-- 1 root root  4059 Feb  9  2018 vcos_queue.h
-rw-r--r-- 1 root root  3526 Feb  9  2018 vcos_quickslow_mutex.h
-rw-r--r-- 1 root root  2940 Feb  9  2018 vcos_reentrant_mutex.h
-rw-r--r-- 1 root root  5673 Feb  9  2018 vcos_semaphore.h
-rw-r--r-- 1 root root  1989 Feb  9  2018 vcos_stdbool.h
-rw-r--r-- 1 root root  3541 Feb  9  2018 vcos_stdint.h
-rw-r--r-- 1 root root  5032 Feb  9  2018 vcos_string.h
-rw-r--r-- 1 root root  3727 Feb  9  2018 vcos_thread_attr.h
-rw-r--r-- 1 root root 10206 Feb  9  2018 vcos_thread.h
-rw-r--r-- 1 root root  4053 Feb  9  2018 vcos_timer.h
-rw-r--r-- 1 root root  2871 Feb  9  2018 vcos_tls.h
-rw-r--r-- 1 root root  9347 Sep 11 05:35 vcos_types.h

./interface/vcos/generic:
total 72
-rw-r--r-- 1 root root  3697 Feb  9  2018 vcos_common.h
-rw-r--r-- 1 root root  2135 Feb  9  2018 vcos_deprecated.h
-rw-r--r-- 1 root root 10060 Feb  9  2018 vcos_generic_blockpool.h
-rw-r--r-- 1 root root  5262 Feb  9  2018 vcos_generic_event_flags.h
-rw-r--r-- 1 root root  3735 Feb  9  2018 vcos_generic_named_sem.h
-rw-r--r-- 1 root root  2902 Feb  9  2018 vcos_generic_quickslow_mutex.h
-rw-r--r-- 1 root root  3220 Feb  9  2018 vcos_generic_reentrant_mtx.h
-rw-r--r-- 1 root root  4814 Feb  9  2018 vcos_generic_tls.h
-rw-r--r-- 1 root root  7781 Feb  9  2018 vcos_joinable_thread_from_plain.h
-rw-r--r-- 1 root root  2719 Feb  9  2018 vcos_latch_from_sem.h
-rw-r--r-- 1 root root  3207 Mar 13  2018 vcos_mem_from_malloc.h
-rw-r--r-- 1 root root  2806 Feb  9  2018 vcos_mutexes_are_reentrant.h
-rw-r--r-- 1 root root  2305 Feb  9  2018 vcos_thread_reaper.h

./interface/vcos/glibc:
total 0

./interface/vcos/pthreads:
total 32
-rw-r--r-- 1 root root  3305 Feb  9  2018 vcos_futex_mutex.h
-rw-r--r-- 1 root root 22142 Mar 13  2018 vcos_platform.h
-rw-r--r-- 1 root root  2994 Feb  9  2018 vcos_platform_types.h

./interface/vcsm:
total 20
-rw-r--r-- 1 root root 17685 Mar 28  2018 user-vcsm.h

./interface/vctypes:
total 28
-rw-r--r-- 1 root root  4356 Mar 28  2018 vc_display_types.h
-rw-r--r-- 1 root root 12166 Aug 17 11:25 vc_image_structs.h
-rw-r--r-- 1 root root  7907 Mar 28  2018 vc_image_types.h

./interface/vmcs_host:
total 312
drwxr-xr-x 3 root root  4096 Jul  2  2018 khronos
drwxr-xr-x 3 root root  4096 Nov 20 18:02 linux
-rw-r--r-- 1 root root 24078 Mar 13  2018 vc_cec.h
-rw-r--r-- 1 root root  6340 Feb  9  2018 vc_cecservice_defs.h
-rw-r--r-- 1 root root 20875 Mar 13  2018 vc_cecservice.h
-rw-r--r-- 1 root root  2579 Feb  9  2018 vc_cma.h
-rw-r--r-- 1 root root  8877 Feb  9  2018 vc_dispmanx.h
-rw-r--r-- 1 root root  8142 Nov 12 12:25 vc_dispmanx_types.h
-rw-r--r-- 1 root root  8013 Feb  9  2018 vc_dispservice_defs.h
-rw-r--r-- 1 root root  8720 Feb  9  2018 vc_dispservice_x_defs.h
-rw-r--r-- 1 root root  4162 Feb  9  2018 vc_fileservice_defs.h
-rw-r--r-- 1 root root  3833 Feb  9  2018 vcfilesys_defs.h
-rw-r--r-- 1 root root  6685 Feb  9  2018 vcfilesys.h
-rw-r--r-- 1 root root  1720 Feb  9  2018 vc_gencmd_defs.h
-rw-r--r-- 1 root root  4419 Nov 12 12:25 vcgencmd.h
-rw-r--r-- 1 root root 23504 Feb  9  2018 vc_hdmi.h
-rw-r--r-- 1 root root  6010 Feb  9  2018 vc_hdmi_property.h
-rw-r--r-- 1 root root 11147 Feb  9  2018 vchost.h
-rw-r--r-- 1 root root  1660 Feb  9  2018 vchost_platform_config.h
-rw-r--r-- 1 root root  4609 Feb  9  2018 vcilcs_common.h
-rw-r--r-- 1 root root  7381 Feb  9  2018 vc_ilcs_defs.h
-rw-r--r-- 1 root root  4272 Feb  9  2018 vcilcs.h
-rw-r--r-- 1 root root  2687 Feb  9  2018 vc_imageconv_defs.h
-rw-r--r-- 1 root root  5766 Mar 13  2018 vc_sdtv.h
-rw-r--r-- 1 root root  2204 Feb  9  2018 vc_service_common.h
-rw-r--r-- 1 root root 12032 Feb  9  2018 vc_tvservice_defs.h
-rw-r--r-- 1 root root 18945 Feb  9  2018 vc_tvservice.h
-rw-r--r-- 1 root root  4491 Feb  9  2018 vc_vchi_audioserv_defs.h
-rw-r--r-- 1 root root  4309 Feb  9  2018 vc_vchi_bufman_defs.h
-rw-r--r-- 1 root root  7522 Feb  9  2018 vc_vchi_bufman.h
-rw-r--r-- 1 root root  2641 Feb  9  2018 vc_vchi_dispmanx.h
-rw-r--r-- 1 root root  2618 Feb  9  2018 vc_vchi_fileservice_defs.h
-rw-r--r-- 1 root root  7744 Feb  9  2018 vc_vchi_filesys.h
-rw-r--r-- 1 root root  4297 Feb  9  2018 vc_vchi_gencmd.h
-rw-r--r-- 1 root root  3137 Mar 13  2018 vc_vchi_gpuserv.h

./interface/vmcs_host/khronos:
total 4
drwxr-xr-x 2 root root 4096 Nov 20 18:02 IL

./interface/vmcs_host/khronos/IL:
total 472
-rw-r--r-- 1 root root  82279 Feb  9  2018 OMX_Audio.h
-rw-r--r-- 1 root root 103360 Nov 12 12:25 OMX_Broadcom.h
-rw-r--r-- 1 root root  23869 Feb  9  2018 OMX_Component.h
-rw-r--r-- 1 root root  71220 Feb  9  2018 OMX_Core.h
-rw-r--r-- 1 root root   3229 Feb  9  2018 OMX_ILCS.h
-rw-r--r-- 1 root root  14684 Feb  9  2018 OMX_Image.h
-rw-r--r-- 1 root root  42246 Aug 17 11:25 OMX_Index.h
-rw-r--r-- 1 root root  37928 Mar 28  2018 OMX_IVCommon.h
-rw-r--r-- 1 root root  18255 Feb  9  2018 OMX_Other.h
-rw-r--r-- 1 root root  13146 Feb  9  2018 OMX_Types.h
-rw-r--r-- 1 root root  45522 Feb  9  2018 OMX_Video.h

./interface/vmcs_host/linux:
total 8
drwxr-xr-x 3 root root 4096 Nov 20 18:02 vcfiled
-rw-r--r-- 1 root root 2227 Feb  9  2018 vchost_config.h

./interface/vmcs_host/linux/vcfiled:
total 8
drwxr-xr-x 3 root root 4096 Jul  2  2018 etc
-rw-r--r-- 1 root root 2020 Feb  9  2018 vcfiled_check.h

./interface/vmcs_host/linux/vcfiled/etc:
total 4
drwxr-xr-x 2 root root 4096 Jul  2  2018 init.d

./interface/vmcs_host/linux/vcfiled/etc/init.d:
total 0

./KHR:
total 12
-rw-r--r-- 1 root root 10389 Feb  9  2018 khrplatform.h

./vcinclude:
total 12
-rw-r--r-- 1 root root 3832 Feb  9  2018 common.h
-rw-r--r-- 1 root root 1745 Mar 13  2018 vc_image_types.h
-rw-r--r-- 1 root root 2164 Feb  9  2018 vcore.h

./VG:
total 60
-rw-r--r-- 1 root root 34098 Feb  9  2018 openvg.h
-rw-r--r-- 1 root root 10064 Feb  9  2018 vgext.h
-rw-r--r-- 1 root root  2414 Feb  9  2018 vgplatform.h
-rw-r--r-- 1 root root  5557 Feb  9  2018 vgu.h

./WF:
total 16
-rw-r--r-- 1 root root 9815 Mar 13  2018 wfc.h
-rw-r--r-- 1 root root 1425 Mar 13  2018 wfcplatform.h

I also have /usr/include/GL, EGL, GL, GL3, GLES, GLES2, GLES3 and now GLFW. But I think I want to use GLFW with /opt/vc/include/GLES

[ab1jx]

Well, that was worthwhile, I updated my userland from github by doing a git pull and built the new version. Hello_teapot still didn't work, it still complained about needing more GPU memory at the CPU/GPU split in raspi-config. 64 MB was always enough for the GPU before but I pushed it up to 128, rebooted, tried it again. No glfw I assume but there's dispmanx, so you could probably make this into a spinning layer.

Now the texture image on the teapot is a Big Buck Bunny clip, which plays as the teapot is spinning and moving around. And it will run without X, but only on a Pi probably. It uses GLES/gl.h, EGL/egl.h and EGL/eglext.h from the /opt/vc/include set that comes with it.

DSCN7941_BBB_teapot_800.jpg (62.79 KiB) Viewed 8724 times

Startling, but I'm glad it's working again.

[ab1jx]

But back to glfw, I'm trying to run simple.c from quick_guide.html and it segfaults. GDB is no help:

Code: Select all

Reading symbols from ./simple...done.
(gdb) run
Starting program: /usr/programs/c/glfw/simple/simple 

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) backtrace
#0  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

Even this segfaults and it's mostly commented out:

Code: Select all

/*
  Trying to open a glfw windo and get a pointer to it
*/

#include <glad/glad.h>
#include <GLFW/glfw3.h>
#include <unistd.h>
//#include <linmath.h> // in /usr/include now
#include <stdlib.h>
#include <stdio.h>

GLFWwindow* window;

int main(void) {
/*
  window = glfwCreateWindow(640, 480, "Simple example", NULL, NULL);
    if (!window)
    {
      printf("glfwCreateWindow failed\n");
        glfwTerminate();
        exit(EXIT_FAILURE);
    }
*/    
  printf("no crash yet\n");
  printf("Window at %x\n",(unsigned int) window);
  sleep(5);
/*  
  glfwDestroyWindow(window);
  glfwTerminate();
*/
  return 0;
}

--------------
It was not calling glfwInit(), or my makefile trying to use pkg-config, I got around it eventually.

[ab1jx]

I have installed (from the Raspbian debs)

Code: Select all

upstairs# dpkg-query -l | grep glfw
ii  libglfw3:armhf                          3.2.1-1                                     armhf        portable library for OpenGL, window and input (x11 libraries)
ii  libglfw3-dev:armhf                      3.2.1-1                                     armhf        portable library for OpenGL, window and input (development files)
ii  libglfw3-doc                            3.2.1-1                                     all          portable library for OpenGL, window and input (documentation)
upstairs#

I copied simple.c from /usr/share/doc/libglfw3-doc/examples/simple.c.gz

The glad.c came from learnopengl.com I think. I have 2 of them, the other one is different than the one I copied into where I compiled it. See http://discourse.glfw.org/t/error-compi ... ng-gcc/730

And got it to compile and run using this Makefile

Code: Select all

CC = gcc
simp:simple.c
        cc -o simp simple.c glad.c -L/usr/lib/arm-linux-gnueabihf -lGL -lm \
        -lXrandr -lXi -lX11 -lXxf86vm -lpthread -ldl -lXinerama -lXcursor -lglfw

simp.png (10.34 KiB) Viewed 8671 times

It rotates as it runs. But at 222% CPU by top, ~75% by the LXDE CPU monitor. This is software OpenGL, not what I'm looking for. It does run in a cute little window I can drag around the screen.

[ab1jx]

Well, somebody got it working on a Mali, there's probably hope for hardware OpenGL ES on a Pi too:

http://discourse.glfw.org/t/building-op ... gles2/1252

From https://www.glfw.org/docs/latest/group_ ... 48952d2033
GLFW_INCLUDE_ES1 makes the GLFW header include the OpenGL ES 1.x GLES/gl.h header instead of the regular OpenGL header.
GLFW_INCLUDE_ES2 makes the GLFW header include the OpenGL ES 2.0 GLES2/gl2.h header instead of the regular OpenGL header.
GLFW_INCLUDE_ES3 makes the GLFW header include the OpenGL ES 3.0 GLES3/gl3.h header instead of the regular OpenGL header.
GLFW_INCLUDE_ES31 makes the GLFW header include the OpenGL ES 3.1 GLES3/gl31.h header instead of the regular OpenGL header.

On a Pi with OpenGL ES 2.1, see http://discourse.glfw.org/t/glfw-on-rpi ... pengl/1215 and
https://github.com/libretro/ludo/pull/93/files but I don't know yet how to use them. Then again I'm just learning OpenGL too. It's dated December 1, 2018, I doubt whatever it patched made its way through the deb process by now.

[tvjon]

I'm currently using 4.19 kernel for a particular project, but presently it won't boot with either fake or real kms in config.txt.

As I'm interested in how well a particular OpenGL application runs, I've built a card using the very interesting 32-64 bit kernels from Sakaki.

$ uname -a
Linux nsp64 4.14.93-v8-24b08c0b745d-bis+ #2 SMP PREEMPT Tue Jan 15 13:26:47 GMT 2019 aarch64 GNU/Linux

I need a ton of libraries building though, so decided to try your simpler examples you've posted about, first.

Both fake & real take approximately the same cpu usage, see attached pic's. Much better than 74%, & the frame rates are fine.
However, no omxplayer et al...

simple+es2gears.jpg (63.89 KiB) Viewed 8591 times

[ab1jx]

Not that it's glfw, but I downloaded https://raw.githubusercontent.com/ehsan ... es2gears.c and worked out this makefile:

Code: Select all

CC = gcc
es2g:es2g.c
        $(CC) -o es2g es2g.c -I/opt/vc/include -L/opt/vc/lib -lm -lEGL -lGLESv2  -lglut

fast_pi_es2gears.png (9.83 KiB) Viewed 8579 times

I have some recent problem (see https://www.raspberrypi.org/forums/view ... 5#p1423435) that causes my gears to be black on a black background. Interesting that building from this source didn't cure that. I tried to use only the Broadcom files but then I had to link a GLUT to get it to compile.

But a tenfold increase in speed, this is faster than the Mali in my Rock64 from memory, I think that was only about 700 FPS.

[6by9]

I'm currently using 4.19 kernel for a particular project, but presently it won't boot with either fake or real kms in config.txt.

Curious.
I know there is an issue with fake KMS stalling during boot on 4.19, but full KMS is working fine for me. Admittedly I'm also testing a Debian Buster build so have a significantly more recent Mesa.
How far does it get during boot for you?

[Gavinmc42]

Interesting, Gentoo64 has Mesa 18.3.1 but Kernel 4.14.90 with fkms-v3d and CMA 256.
Switching to kms-v3d does not work, it give a blank screen, a reboot brings back up fkms mode.
Sakaki makes it hard for me to break Gentoo64 these days, it can fix itself .

Wonder if anyone has kernel 5.x working yet?

Mesa 18.x does seem to work better than 13.x
I think there are also Pi improvements in 4.19 but my plays with BRANCH=next did not interest me enough to run many tests.
I was more interested in playing with OpenGL in aarch64

[6by9]

Interesting, Gentoo64 has Mesa 18.3.1 but Kernel 4.14.90 with fkms-v3d and CMA 256.
Switching to kms-v3d does not work, it give a blank screen, a reboot brings back up fkms mode.
Sakaki makes it hard for me to break Gentoo64 these days, it can fix itself .

Wonder if anyone has kernel 5.x working yet?

Mesa 18.x does seem to work better than 13.x
I think there are also Pi improvements in 4.19 but my plays with BRANCH=next did not interest me enough to run many tests.
I was more interested in playing with OpenGL in aarch64

(Going off topic)
4.14 with Raspbian boots fine with full KMS, so I don't know what has been done with Gentoo64.
I'm working solely on 4.19 now. There are a bundle of patches gone in to fix up numerous build warnings in the downstream drivers with arm64, though very few were likely to cause any real problems.
The V4L2 camera driver is working on arm64, and I have all the patches to get the V4L2 codec driver working. I've had GStreamer playing videos with hardware acceleration on arm64 to kmssink or glimagesink, so multimedia on arm64 is nearly there. I need to double check encode, but it should be fine too.

Yes, I have booted an upstream 5.0 kernel and it worked reasonably. Nothing particularly exciting in it, and won't get much attention from us as it isn't an LTS kernel.

[tvjon]

...
I know there is an issue with fake KMS stalling during boot on 4.19, but full KMS is working fine for me. Admittedly I'm also testing a Debian Buster build so have a significantly more recent Mesa.
How far does it get during boot for you?

Just the black screen as I mentioned in another post. I'll try to find my serial cable & give you something more useful.

Do you have a pointer to that Buster image that I can put on a card, then I can try it for you?

This µSD card is now:

$ uname -a
Linux sa1 4.19.17-v7+ #1196 SMP Thu Jan 24 14:59:34 GMT 2019 armv7l GNU/Linux

[6by9]

Just the black screen as I mentioned in another post. I'll try to find my serial cable & give you something more useful.

So that's what I get with fake KMS - it's getting most of the way through booting and mounting stuff, and then stalls. I suspect something isn't correctly linked together/initialising within the display drivers - they did work recently for things such as not stalling should a DSI screen not be connected at boot.

Do you have a pointer to that Buster image that I can put on a card, then I can try it for you?

I believe it's in progress as an alpha release - Buster is expected to release around June/July this year, and is considered unstable at the moment.
I got given an SD card to clone by Simon.

[Gavinmc42]

I'm working solely on 4.19 now. There are a bundle of patches gone in to fix up numerous build warnings in the downstream drivers with arm64, though very few were likely to cause any real problems.
The V4L2 camera driver is working on arm64, and I have all the patches to get the V4L2 codec driver working. I've had GStreamer playing videos with hardware acceleration on arm64 to kmssink or glimagesink, so multimedia on arm64 is nearly there. I need to double check encode, but it should be fine too.

Looks like time to go back and try 4.19 now.
Wonder if it will work on Sakaki's new dual 32/64 Debian?
Weekend starts tonight Pi breaking time?

[Orange]

I've got glfw running on a Raspberry Pi 4 with 4.19 Raspbian, including the triangle-opengl example. To save everybody a ton of time here is how I did it.

Forget messing around with 64-bit versions of Linux. Just install the latest 32-bit version of Raspbian which will have all the nice OpenGL hardware acceleration enabled by default.

Install Dependencies

sudo apt install git
sudo apt install xorg-dev

Download and install GLFW as follows (as user pi):

cd $home
git clone https://github.com/glfw/glfw
cd glfw
cmake -DBUILD_SHARED_LIBS=ON .
make
sudo make install

The download includes some nice examples, including triangle-opengl but that won't run yet as it targets the wrong version of OpenGL. The Raspberry Pi 4 supports up to OpenGL ES 3.1 so make the following changes to examples/triangle-opengl.c

Around line 89 replace the glfwWindowHint lines with the following ones:

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, 0);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

Around line 51 replace the #version line (vertex shader) with the following line:

"#version 310 es\n"

Around line 63 replace the #version line (fragment shader) with the following 2 lines:

"#version 310 es\n"
"precision mediump float;\n"

Now build and run the triangle-opengl example as follows:

make triangle-opengl
./examples/triangle-opengl

If all is well you should see a window with a spinning colourful triangle in it.

Good luck!