Thread from Pi4 discussion

[PeterO]

What I'm not clear about is how the new architecture interacts with the hardware..
The frames per second performance of that example is not what would have expected, which leads me to think it isn't using the hardware to
got the openGLES rendering but is using slower arm side "new" stuff ?.

What resolution are you running and what framerate are you seeing?
I'm seeing about 24fps at 1080p.

That's odd, I'm seeing ~50fps. I converted it into C (I don't do C++) but had to add -I/opt/vc/include so gcc could find gl2.h
But it then goes on to link with libGLES2.so from /usr/lib/gnueabihf/libGLESv2.so

The c++ version wont compile as it complains about a couple of things...

Code: Select all

test.cc: In function ‘int main()’:
test.cc:287:62: error: invalid conversion from ‘Window’ {aka ‘long unsigned int’} to ‘EGLNativeWindowType’ {aka ‘void*’} [-fpermissive]
    egl_surface = eglCreateWindowSurface ( egl_display, ecfg, win, NULL );
                                                              ^~~
In file included from test.cc:22:
/opt/vc/include/EGL/egl.h:266:27: note:   initializing argument 3 of ‘void* eglCreateWindowSurface(EGLDisplay, EGLConfig, EGLNativeWindowType, const EGLint*)’
       EGLNativeWindowType win,
       ~~~~~~~~~~~~~~~~~~~~^~~

What did you do to get it to compile ?

That will be using hardware. For every pixel it is calculating

Code: Select all

vec4( 1., 0.9, 0.7, 1.0 ) *     \
        cos( 30.*sqrt(pos.x*pos.x + 1.5*pos.y*pos.y)   \
             + atan(pos.y,pos.x) - phase );

which is a *lot* of trig operations per second.

I didn't look at the shader code so I didn't realise it was quite so maths heavy !

PeterO

PS: Maybe we should take this over to the graphics programming/OpenGLES forum ?

[dom]

I just followed the instructions in the comments and it compiled with no changes.

Code: Select all

pi@domnfs:~/projects/gl $ g++  -lX11 -lEGL -lGLESv2  egl-example.cpp
pi@domnfs:~/projects/gl $ ./a.out

[dom]

Oh - you may need:

Code: Select all

sudo apt-get install libgles2-mesa-dev

(best not to use the /opt/vc/include ones - they are for a different driver).

[PeterO]

That's weird ! I'm on a fresh (but updated) raspian.
g++ version is .....

pi@raspberrypi:~ $ g++ --version
g++ (Raspbian 8.3.0-6+rpi1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

PeterO

[PeterO]

Oh - you may need:

Code: Select all

sudo apt-get install libgles2-mesa-dev

(best not to use the /opt/vc/include ones - they are for a different driver).

Ok I'll try that.
....
That fixed the compile And it's getting 48-50 fps. I have 128M of GPU memory if that makes a difference.

PeterO

[dom]

That fixed the compile And it's getting 48-50 fps. I have 128M of GPU memory if that makes a difference.

Shouldn't make a difference - gpu mem is needed by legacy driver, but arm side driver can just use normal arm memory.

[PeterO]

I thought I've asked before but I can't find it now.... Is there a description of the relation ship between the "Legacy Driver" , "The ARM Side Driver" and the actual hardware ? At the moment it's unclear to me what processing happens where and what is hardware accelerated and what isn't. Previously I thought that anything "mesa" related was all done in software (and historically was very slow). Note that I've not been keeping up to date with GL developments for a few years now.

PeterO

[gustafla]

EDIT: sorry I missed the fact that posts need to be approved before showing. Ignore this one and read the one below :p

Mesa is a generic open source driver stack that supports a lot of hardware and is the best OpenGL implementation for the intel (i915), radeon and amdgpu, as well as nouveau kernel drivers. Mesa also has a software renderer but it's rarely used in a desktop context. So typically on a Linux open source driver stack, hardware abstraction and management (DRM) is in the corresponding kernel driver (examples listed above) and the mesa user-space library translates graphics API calls from applications to hardware operations with the help of the kernel driver. But I don't really know about the VideoCore VI situation. I only have a hunch that on VC4 the DRM driver had to hack around some hardware limitations and thus requires more memory bandwidth and cpu time than the legacy brcm driver. IIRC, the "legacy driver" (bcm_host) is just pretty much passing OpenGL ES calls to the GPU which actually does most of the OpenGL state keeping in the firmware. And I think I read that since the Pi 4 GPU now has a MMU, the new DRM+Mesa driver should be lower overhead.

[gustafla]

On a typical Linux PC with a free graphics stack there is kernel level hardware abstraction (called DRM) implemented in one of these drivers: intel/i915, amdgpu, radeon or nouveau, depending on hardware.

The userspace OpenGL implementation libarary is Mesa, and when applications call glWhatever(), the symbol is located in Mesa's libGL.so and Mesa keeps track of the OpenGL state in that applications context. Mesa commands the suported graphics hardware to do the job or manages the graphics memory accordingly, through the DRM API in the kernel driver.

Mesa can software render too, but that is very rarely used in a desktop user context because most graphics hardware has good enough DRM drivers and support by Mesa.

VideoCore 4 nowadays has a DRM+Mesa driver ("Desktop OpenGL driver" in rpi-config), but I've head it's somewhat slower and requires more memory and CPU time because the VC4 is really just an old mobile GPU without an IOMMU and things have to be emulated or worked around.

The "legacy driver" is the libbcm_host.so and libbrcmGLESv2.so (previously just libGLESv2.so), which are independent of Mesa, X.Org and DRM. When using that, you have to call bcm_host_init() and create an output surface using dispmanx (Broadcom's own display compositing API). The resulting "window" is actually not recognized by X.Org at all, and just floats on top of everything, even the Linux console. However, the "legacy" driver has much lower overhead because it only supports the specific OpenGL ES 2.0 calls that the underlying hardware does, and it offloads a lot of the state keeping and heavy lifting to the VideoCore 4 GPU firmware.

I don't know much about VideoCore VI, but I've heard that it's more modern and can be supported better by DRM+Mesa because it has an IOMMU. I hope it's also capable of good Vulkan support.

[PeterO]

Mesa can software render too, but that is very rarely used in a desktop user context because most graphics hardware has good enough DRM drivers and support by Mesa.

I think this must have been the case when I last took a serious look at openGL, so thanks for clearing that up.
PeterO

[PeterO]

Oh - you may need:

Code: Select all

sudo apt-get install libgles2-mesa-dev

(best not to use the /opt/vc/include ones - they are for a different driver).

Ok I'll try that.
....
That fixed the compile And it's getting 48-50 fps. I have 128M of GPU memory if that makes a difference.

PeterO

Dom,

if you take out this code, it renders into an X window rather than going full screen. (around line 213 in my C version)

Code: Select all

 
#if 0 
   atom = XInternAtom ( x_display, "_NET_WM_STATE_FULLSCREEN", True );
   XChangeProperty (
      x_display, win,
      XInternAtom ( x_display, "_NET_WM_STATE", True ),
      XA_ATOM,  32,  PropModeReplace,
      (unsigned char*) &atom,  1 );
 #endif
 

I'm now getting 60fps which I guess is locked to the refresh rate. Would it be better to run the "hello_xxxxx" demos in a window rather than full screen ?

I also suspect there is a better way than using those (somewhat old fashioned (though still functional)) Xlib calls to get a window
PeterO

[6by9]

Pi4 is now using Mesa and DRM.
The 3D side is in kernel module "v3d", with the DRM side in "vc4" (common with earlier Pis). On earlier Pis the 3D side was also in "vc4".
Yes, Mesa has support for both 3D parts.

vc4 has no IOMMU, but v3d does, so with Pi4 there is significantly less contention on the CMA heap for memory which was the main headache for vc4.
Performance wise, vc4 and the legacy driver are at approximately the same performance level now.

[PeterO]

Pi4 is now using Mesa and DRM.
The 3D side is in kernel module "v3d", with the DRM side in "vc4" (common with earlier Pis). On earlier Pis the 3D side was also in "vc4".
Yes, Mesa has support for both 3D parts.

vc4 has no IOMMU, but v3d does, so with Pi4 there is significantly less contention on the CMA heap for memory which was the main headache for vc4.
Performance wise, vc4 and the legacy driver are at approximately the same performance level now.

A picture would help

PeterO

[PeterO]

Dom,

Here is "triangles2" running in a window on Pi4

triangle2.png (25.72 KiB) Viewed 13100 times

Well it is running but not taking any mouse input yet.

PeterO

Update: And now it's picking up mouse motion as well

I've used GTK3 to create the window and to collect pointer motion events. The rendering is done in an idle handler from the gtk main event loop.

PeterO

[gustafla]

Has anyone tried SDL2 + GL on Buster? That should work seamlessly even on Pi3 but I have never tried. Here's my example code: https://github.com/gustafla/badgl

[PeterO]

Just tried my code on Pi3B with Buster , as expected it works
I also tried in on my X86-64 Mint-19 box, and it compiled and worked as-is with no modification required

PeterO

[dom]

Just tried my code on Pi3B with Buster , as expected it works
I also tried in on my X86-64 Mint-19 box, and it compiled and worked as-is with no modification required

Is your code available somewhere? Might be useful to other users trying to do a similar thing.

[PeterO]

Just tried my code on Pi3B with Buster , as expected it works
I also tried in on my X86-64 Mint-19 box, and it compiled and worked as-is with no modification required

Is your code available somewhere? Might be useful to other users trying to do a similar thing.

Will be once I tidy it up. Just experimenting with best place to perform the egl initialisation once the Gtk window has been created.

PeterO

[Brian Beuken]

ok if I read this right? if we want to use GLES3.0 we need to set up an Xwindow system and use Mesa libs?

[PeterO]

ok if I read this right? if we want to use GLES3.0 we need to set up an Xwindow system and use Mesa libs?

That is how the code that Dom pointed me at works, so I'm assuming that's the way to do it. I don't know if it can still be done full screen via dispmanx (i.e. without interaction with X) like it used to work.

PeterO

EDIT: I think this explains it:
https://www.raspberrypi.org/forums/view ... 0#p1486236
PeterO

[Brian Beuken]

ok if I read this right? if we want to use GLES3.0 we need to set up an Xwindow system and use Mesa libs?

That is now the code that Dom pointed me at works, so I'm assuming that's the way to do it. I don't know if it can still be done full screen via dispmanx (i.e. without interaction with X) like it used to work.

PeterO

EDIT: I think this explains it:
https://www.raspberrypi.org/forums/view ... 0#p1486236
PeterO

ok
I can do full screen X11 windows on other systems, I will see if I can adapt that code to Pi4

[PeterO]

ok if I read this right? if we want to use GLES3.0 we need to set up an Xwindow system and use Mesa libs?

That is now the code that Dom pointed me at works, so I'm assuming that's the way to do it. I don't know if it can still be done full screen via dispmanx (i.e. without interaction with X) like it used to work.

PeterO

EDIT: I think this explains it:
https://www.raspberrypi.org/forums/view ... 0#p1486236
PeterO

ok
I can do full screen X11 windows on other systems, I see if I can adapt that code to Pi4

It doesn't need any adapting, it just works, though see doms comments about requirements for compiling.

PeterO

[dom]

ok if I read this right? if we want to use GLES3.0 we need to set up an Xwindow system and use Mesa libs?

You must use mesa libs (that is where the 3d driver is for kms/fkms, and Pi4 only supports fkms).

X isn't essential. Kodi for example runs as a fullscreen app.
Note: you can only have one master of the display.
That means fullscreen 3d apps have to either run without X running, or at least switch to a different VT
(e.g. ctrl-alt-F2) to launch. Obviously you can have a wrapper script that handles this if you want to launch from X but have access to fullscreen.

[hexelpdkk]

The gles3 book samples all compile and work unmodified (https://github.com/danginsburg/opengles3-book) with cmake and libgles2-mesa-dev installed - at least all the ones I have run so far worked.

[Brian Beuken]

hmm I am having some issues, just trying to get gles2.0 projects that work on Pi3's to run.
It builds ok against mesa libs, but at different gl or egl commands it freezes.

Is there a step by step guide on how to configure the Pi4 to build GLES2.0 and GLES3.0 projects?