Raspberry Pi Forums

Posted: **Tue Jun 25, 2019 8:26 pm**

dom wrote: ↑
Tue Jun 25, 2019 7:46 pm

PeterO wrote: ↑
Tue Jun 25, 2019 7:04 pm
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 ?

Posted: **Tue Jun 25, 2019 8:37 pm**

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

Posted: **Tue Jun 25, 2019 8:39 pm**

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).

Posted: **Tue Jun 25, 2019 8:42 pm**

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

Posted: **Tue Jun 25, 2019 8:46 pm**

dom wrote: ↑
Tue Jun 25, 2019 8:39 pm
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

Posted: **Tue Jun 25, 2019 9:46 pm**

PeterO wrote: ↑
Tue Jun 25, 2019 8:46 pm
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.

Posted: **Wed Jun 26, 2019 4:38 am**

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

Posted: **Wed Jun 26, 2019 10:01 am**

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.

Posted: **Wed Jun 26, 2019 10:24 am**

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.

Posted: **Wed Jun 26, 2019 2:17 pm**

gustafla wrote: ↑
Wed Jun 26, 2019 10:24 am
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

Posted: **Wed Jun 26, 2019 2:21 pm**

PeterO wrote: ↑
Tue Jun 25, 2019 8:46 pm
dom wrote: ↑
Tue Jun 25, 2019 8:39 pm
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

Posted: **Wed Jun 26, 2019 3:11 pm**

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.

Posted: **Wed Jun 26, 2019 3:48 pm**

6by9 wrote: ↑
Wed Jun 26, 2019 3:11 pm
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

Posted: **Wed Jun 26, 2019 6:27 pm**

Dom,

Here is "triangles2" running in a window on Pi4

: triangle2.png (25.72 KiB) Viewed 8994 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

Posted: **Wed Jun 26, 2019 7:40 pm**

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

Posted: **Thu Jun 27, 2019 8:35 am**

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

Posted: **Thu Jun 27, 2019 11:21 am**

PeterO wrote: ↑
Thu Jun 27, 2019 8:35 am
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.

Posted: **Thu Jun 27, 2019 11:43 am**

dom wrote: ↑
Thu Jun 27, 2019 11:21 am

PeterO wrote: ↑
Thu Jun 27, 2019 8:35 am
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

Posted: **Thu Jun 27, 2019 11:54 am**

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?

Posted: **Thu Jun 27, 2019 12:21 pm**

Brian Beuken wrote: ↑
Thu Jun 27, 2019 11:54 am
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

Posted: **Thu Jun 27, 2019 1:12 pm**

PeterO wrote: ↑
Thu Jun 27, 2019 12:21 pm

Brian Beuken wrote: ↑
Thu Jun 27, 2019 11:54 am
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

Posted: **Thu Jun 27, 2019 1:25 pm**

Brian Beuken wrote: ↑
Thu Jun 27, 2019 1:12 pm

PeterO wrote: ↑
Thu Jun 27, 2019 12:21 pm

Brian Beuken wrote: ↑
Thu Jun 27, 2019 11:54 am
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

Posted: **Thu Jun 27, 2019 2:59 pm**

Brian Beuken wrote: ↑
Thu Jun 27, 2019 11:54 am
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.

Posted: **Thu Jun 27, 2019 5:38 pm**

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.

Posted: **Fri Jun 28, 2019 1:17 am**

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?

Raspberry Pi Forums

Thread from Pi4 discussion

Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion

Re: Thread from Pi4 discussion