Where's my Triangle??

[PeterO]

I've not looked back to my 3B+ since I got a 4B, but it is my understanding that the EGL interface is only available on the 4B and that on earlier models you still have to use DispmanX to get a rendering surface. But I could be wrong

But I've often said that the documentation on the whole graphics stack is lacking and there is no single place that clearly explains the relationships between parts and what is/is not available on different models and with different bits of software and firmware enabled.

PeterO

No, egl is available, that was never an issue, only the means of getting on screen was confusing on 3B, I used DispmanX (we discussed why before) and it workes perfectly well. here for example is my usual RPi (not 4) setup which works fine

See I told you it is confusing ! You are right, it's not EGL that's different, it's where you get the surface for EGL to use that is different.
Pre Pi4 it was DispmanX
Post Pi4 it is X11 (which is why you can now display openGLES in an X11 window (or even in a GTK+ widget).

I realise now effectivly X11 is pumping that dispmanX bitmap to the screen every frame, but thats fine.

Is it ? I though the "compositor" got in on the act somewhere (but where is the diagram that shows how it all fits together ????)

PeterO

[Brian Beuken]

Is it ? I though the "compositor" got in on the act somewhere (but where is the diagram that shows how it all fits together ????)

PeterO

I'm getting to that...wibble wobble, just kill me, I can't keep track phase..... All I know is that code works 100% on all Rpi's up to the 4 and the X11 code works on every other linux except Rpi's up to 4

Coding is fun

[PeterO]

Is it ? I though the "compositor" got in on the act somewhere (but where is the diagram that shows how it all fits together ????)

PeterO

I'm getting to that...wibble wobble, just kill me, I can't keep track phase..... All I know is that code works 100% on all Rpi's up to the 4 and the X11 code works on every other linux except Rpi's up to 4

I'm only going on comments I've seen where the compositor has been fingered for causing bottle necks and slow frame rates. Suggestions to turn it off (not sure how) come with warnings about poor performance when repositioning windows with the mouse.

Coding is fun

Most of the time !
PeterO

[Gavinmc42]

I have gone headless and I'm using Lite versions, then I install and play with various Window Managers.
Basic x11 without bells and whistles so I can reduce side effects and possibly learn what is going on.
Then I will try Wayland, by then I should be closer to going baremetal.

Playing with Python GLSL Shaders stuff on just a basic x11 setup is fun.
Lots to learn before I get to a baremetal version, but I cheat and use Ultibo anyway.

OpenGLES 3.1 will be interesting, I did not have much luck with 3.0 extensions.
Raspbian is still the best supported OS, going outside that is a steep learning curve.

Cool, the new Gentoo64 Lite with basic x11 just finished emerging.
Now need to update mesa to latest version

Edit - Sakaki's support of Gentoo64 is good, just emerged mesa-progs and glxinfo reports 19.3.2.

[Brian Beuken]

I'm only going on comments I've seen where the compositor has been fingered for causing bottle necks and slow frame rates. Suggestions to turn it off (not sure how) come with warnings about poor performance when repositioning windows with the mouse.

The slow down I saw with mesa EGL and GLESv2 was almost certainly due to emulation, Mesa libs do not always recognise the VC GPU and it goes into standard CPU emulation, ie it will work, but at a fraction of the GPU's speed. When its in emulation mode the compositor is the least of your worries. Mesa does however recognise the Pi4's VC GPU and accelerates that just fine.

I guess the lesson is to use the drivers and display systems best suited to the particular machine.

[Brian Beuken]

of course, I'm probably totally wrong... I've been wrong about everything else

[Daniel Gessel]

When using dispmanx to create a surface for GL rendering, you get an overlay, which is a second framebuffer the scanout hardware composes with the standard X11framebuffer.

This is different than using the GPU to composite X11 windows, which is done by xcompmgr via GL calls all in a single display framebuffer. Killing xcompmgr turns off this compositing and it can be restarted simply by launching it again.

To get GPU accelerated OpenGL on X11 pre Pi4, you must use one of the kms drivers, not the legacy driver. This is selectable using raspi-config. Part of the reason X11 GL works out of the box on Pi4 is there are no legacy drivers for the Pi4.

[Brian Beuken]

I always use Legacy drivers and OpenGLES2.0
OpenGL is nice but there's a few things emulated that impact on performance, much better in my mind to use the systems the GPU was intended to use.

[Daniel Gessel]

I always use Legacy drivers and OpenGLES2.0
OpenGL is nice but there's a few things emulated that impact on performance, much better in my mind to use the systems the GPU was intended to use.

Apologies, I wasn’t clear: I meant that getting GPU accelerated OpenGL orGLES in an X window requires using KMS drivers - the use of the legacy drivers is why you saw such poor performance.

The overlay path has the advantage that it should be able to support page flipping without having to go full screen.

[Brian Beuken]

I always use Legacy drivers and OpenGLES2.0
OpenGL is nice but there's a few things emulated that impact on performance, much better in my mind to use the systems the GPU was intended to use.

Apologies, I wasn’t clear: I meant that getting GPU accelerated OpenGL orGLES in an X window requires using KMS drivers - the use of the legacy drivers is why you saw such poor performance.

The overlay path has the advantage that it should be able to support page flipping without having to go full screen.

Ah, yes that makes sense, ok I'l try that later, thanks.

[Brian Beuken]

hmmm no
on a 3B with KMS full drivers trying to set up an X11 system results in this error
* failed to add service - already in use?

thrown when I try to call eglGetDisplay(EGL_DEFAULT_DISPLAY);

wibble wobble....sigh....

[6by9]

hmmm no
on a 3B with KMS full drivers trying to set up an X11 system results in this error
* failed to add service - already in use?

thrown when I try to call eglGetDisplay(EGL_DEFAULT_DISPLAY);

wibble wobble....sigh....

"* failed to add service - already in use?" means you've linked against the firmware legacy GLES library, not against mesa.

[PeterO]

"* failed to add service - already in use?" means you've linked against the firmware legacy GLES library, not against mesa.

Where is that written down ?
PeterO

[6by9]

"* failed to add service - already in use?" means you've linked against the firmware legacy GLES library, not against mesa.

Where is that written down ?

https://github.com/raspberrypi/userland ... nux.c#L214

[PeterO]

"* failed to add service - already in use?" means you've linked against the firmware legacy GLES library, not against mesa.

Where is that written down ?

https://github.com/raspberrypi/userland ... nux.c#L214

That's just a very disappointing "use the source Luke" reply.
For an organisation that claims to be all about education you really need to provide a better level of documentation of the code you produce.

PeterO

[Brian Beuken]

ok I'll make a few changes to use the mesa libs and report back, but have to agree with PeterO, its not supposed to be a treasure hunt.

[6by9]

AFAIK None of out educational resources cover open gl/gles as it is a pretty advanced topic.

Googling the error message is normally the first port of call when debugging these days. Finding the code that logs it gives a pretty good idea of what you're doing wrong.

[Brian Beuken]

AFAIK None of out educational resources cover open gl/gles as it is a pretty advanced topic.

Googling the error message is normally the first port of call when debugging these days. Finding the code that logs it gives a pretty good idea of what you're doing wrong.

I think they should, while its a fair point that a RPi is vastly inferior to a full PC/Laptop and isn't really going to be used as a graphics system, the ability to use a GPU is considerably easier to get your head around, on a restricted system that works as it should, and is a great teaching aid for graphic programmers starting out on OpenGL of any flavour.

I'll report back on the use of mesa drivers when I get a chance to do some coding, bit busy at work at the moment.

[PeterO]

AFAIK None of out educational resources cover open gl/gles as it is a pretty advanced topic.

That's not a reason for not documenting it !
And CodeClub already have Blender projects, so 3D concepts are already included in educational resources and 3D programming could be too. Using pi3d could easily be included in the CodeClub python projects.

Googling the error message is normally the first port of call when debugging these days. Finding the code that logs it gives a pretty good idea of what you're doing wrong.

Except that in this case google produced nothing useful.
As I keep saying I find the documentation around the 3D features to be very lacking, especially compared to the openGLES documentation.
PeterO

[6by9]

Googling the error message is normally the first port of call when debugging these days. Finding the code that logs it gives a pretty good idea of what you're doing wrong.

Except that in this case google produced nothing useful.
As I keep saying I find the documentation around the 3D features to be very lacking, especially compared to the openGLES documentation.
PeterO

First hit for me on

Code: Select all

gles "failed to add service - already in use"

https://raspberrypi.stackexchange.com/q ... mmatically

Per the Stack Overflow link below, this can be worked around by commenting out dtoverlay=vc4-kms-v3d in config.txt. Unfortunately that disables OpenGL, leading to odd configuration restrictions like being unable to run both Quake 3 and full Minecraft without rebooting.

Fourth hit was https://github.com/raspberrypi/firmware ... -507422290

Just to add, I managed to get around that hurdle by adding /opt/vc/include to the C_INCLUDE_PATH environment variable, allowing me to disable RPI in SDL and also keep GLES1. Unfortunately, I just receive "failed to add service - already in use?" when loading Enemy Territory - this is something I've come across in the past when using the kms/fkms driver with GLES.

Adding /opt/vc/include doesn't sound like the right solution. That is likely finding the firmware gl includes, rather than the desired mesa ones (in /usr/include). Do you have mesa installed (libgles2-mesa-dev)?

How can I fix this in the source code of GLES apps while still linking with the Broadcom VideoCore GLES/EGL libraries? Note that although such apps could be ported to avoid dispmanx and use the Mesa open-source driver instead, performance would take a hit.

That should have given you a big hint that you're linking against the wrong libraries.


And please note that the Raspberry Pi Foundation and their associated brands (eg CodeClub) generate most of the educational materials, not Raspberry Pi Trading.
And there is a world of difference between using Blender as an application vs programming GL for yourself.