Raspberry Pi Forums

Posted: **Fri Nov 22, 2019 5:15 pm**

Hi!
I've just tried some simple OpenGLES examples on my R-Pi 3, and it looks like the things have got worse than before.
Lots of thing used to work a year ago, however everything I try seems to fail now.

For example, SDL2 + OpenGLES used to work with the KMS OpenGL driver according to:
https://www.youtube.com/watch?v=u-quGjXq7Wk
https://github.com/timskillman/raspberrypi

However, SDL2 + OpenGLES works only with legacy OpenGL drivers, which is extremely slow.
With KMS GL enabled it fails to create GL context with the following message: "Could not create GL congext: GLXBadFBConfig".

I've also tried the example from /opt/vc/src/hello_pi/hello_triangle.
This doesn't work with KMS as well showing "failed to add service - already in use?" message.
Is it still possible to use OpenGLES and have some decent performance with h/w acceleration?

I'm using the latest Raspbian Buster. I've also tried building the latest SDL libs from source with no luck.

Does anyone have a working GLES + KMS GL driver example for Raspbian?
Do I need to use any alternative OS to get decent OpenES performance?
Any help is greatly appreciated!

Thanks,
V.

Posted: **Wed Nov 27, 2019 6:25 pm**

The fakeKMS driver will run GLES code and seems to run GL and GLES2 or GLES3 code at the same speed, and pretty much at the same speed as on the RPi3. See some comparisons I did here. Not sure what language you are interested in. Is that error from running the code on github.com/skillman/raspberrypi? I know he has updated his code but not yet made it public. It looks to be a GLX error and I'm not sure exactly where that crops up in that code - but the last version of pi3d (v2.34) uses GLX to render transparent X11 windows and it runs ok on raspbian buster.

for CPP I think Tim's code works fine on RPi4 just using the standard raspbian sdl2 (i.e.

Code: Select all

 sudo apt-get install libsdl2-dev
 sudo apt-get install libsdl2-mixer-dev
 sudo apt-get install libsdl2-ttf-dev
 sudo apt-get install libsdl2-image-dev
 sudo apt-get install libsdl2-net-dev

Have you set the graphics driver to fakeKMS in raspi-config?

Here is a rust version of pi3d that I did.

And here is the python pi3d that runs on the RPi4 at least as fast as on the older GLES only machines.

Posted: **Wed Nov 27, 2019 7:04 pm**

I use raspi-config for switching graphic drivers.

Yes, I get this error when using KMS with Tim's code as well. I'm not sure whether it's possible to use sdl2 with KMS.
I think sdl2-config --cflags adds -L/opt/vc/lib which causes proprietary OpenGL libraries to be linked as well.
It looks like I can't use the proprietary libraries from /opt/vc/lib with KMS drivers. It shows the "failed to add service - already in use?" message.
AFAIU, that's expected behaviour.

However, Tim's code runs at 0.2fps with the non-KMS driver. I guess that's because it doesn't actually initialize the display with brcm code,
using SDL2 + X11 instead, which doesn't support h/w acceleration at all.

Thank you, I'll try your pi3d later.

I've tried simple tests with the legacy non-GL drivers and proprietary libs in /opt/vc/lib, and fake/full KMS with mesa OpenGL libs. I can't seem to get more than 30fps at 1920x1080 full screen with KMS. Even "vblank_mode=0 glxgears -fullscreen" shows about 30fps,
while simple examples from /opt/vc/src show 177 fps with vblank sync disabled (eglSwapInterval(0)).
When vblank sync is enabled I get 60fps (limited by my HDMI display).
Looks like KMS is significantly slower than the legacy driver.

Thanks,
Val.

Posted: **Wed Nov 27, 2019 8:16 pm**

Yes it is a bit odd. Just read your other thread and seen the eglSwapInterval(0) tip. The SDL2 route doesn't use EGL (unless SDL2 does something behind the scenes) but there is an SDL function (also exposed in the rust crate) to set SwapInterval. I tried it on one of the rust_pi3d demos and the fps stuck at 60 as before. Also in the python code. However I think this is a limitation of my screen which is pretty ancient and I have to run via VGA (the HDMI adapter just doesn't seem to work). I downloaded and compiled Tim's raspberrypi code and the screen blanks with a hardware warning window saying that 67.4 is faster than 60.0

I always set the driver to fake KMS though I noticed in Tim's readme that he specifies full KMS. I can't remember if I tried full and it gave errors. It's definitely possible to use SDL2 with fake KMS.

Posted: **Wed Nov 27, 2019 11:20 pm**

I've finally managed to start Tim's demo with the KMS drivers. The following changes did the trick:

Code: Select all

diff --git a/SharedCode/SMwin.cpp b/SharedCode/SMwin.cpp
index 8bddf54..63706d7 100644
--- a/SharedCode/SMwin.cpp
+++ b/SharedCode/SMwin.cpp
@@ -60,7 +60,7 @@ bool SDLwindow::init(const char * title, int width, int height, uint32_t flags,
 		mHeight = height;
 		SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
 		SDL_GL_SetAttribute(SDL_GL_BUFFER_SIZE, 32);
-		SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 32);
+		SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);
 		SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, majvsn);
 		SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, minvsn);
 		SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);

The "./SceneViewer -scene Bridge.scene" shows 16 fps at 1920x1080 fullscreen (256MB GPU RAM).

I've also managed to start ScreenRunner demo with additional shader changes:

Code: Select all

--- a/Projects/ScreenRunner/Shaders/fs1.glsl
+++ b/Projects/ScreenRunner/Shaders/fs1.glsl
@@ -1,5 +1,5 @@
-#version 120
-//precision mediump float;       	// Set the default precision to medium
+#version 100
+precision mediump float;       	// Set the default precision to medium
 
 uniform sampler2D u_Texture;   	// texture
 varying vec2 v_UV;				// Texture UV coordinate
diff --git a/Projects/ScreenRunner/Shaders/vs1.glsl b/Projects/ScreenRunner/Shaders/vs1.glsl
index 011a577..a7a9541 100644
--- a/Projects/ScreenRunner/Shaders/vs1.glsl
+++ b/Projects/ScreenRunner/Shaders/vs1.glsl
@@ -1,5 +1,5 @@
-#version 120
-//precision mediump float;       // Set the default precision to medium. We don't need as high of a
+#version 100
+precision mediump float;       // Set the default precision to medium. We don't need as high of a
 
 uniform mat4 u_ProjMatrix;     // view/projection matrix.
 uniform mat4 u_ModelMatrix;    // model matrix.

It shows about 35fps at 1920x1080.

Probably, the above changes are needed on Pi3 only.
I'm using the latest Raspbian Buster, BTW.

SDL_GL_SetSwapInterval(0) does disable vsync for me.
I've managed to get over 100 fps at 640x480, while it's 60 with vsync enabled.
Not sure why it's not working for you. Probably it's not implemented correctly in ruby/python.

Unfortunately, I couldn't build pi3d. It shows a number of "Use of unstable feature/library"
errors, and eventually stops with "error: Could not compile `arrayvec`".
Would be interesting to give it a try on my HDMI display and see if I get the same vsync behaviour.

BTW, fake KMS works equally fast, and I've seen some comments that it's preferred to the full KMS version.
Personally I find full KMS less stable as I get black screen with some applications, such as vlc, running
in fullscreen mode.

Thanks,
Val.

Posted: **Thu Nov 28, 2019 11:22 am**

I don't use anything except fakeKMS on Pi4 Gentoo64.
Real KMS is still a work in progress one of the Pi guys said recently.
I set the shader version to 300 es.

Posted: **Thu Nov 28, 2019 12:31 pm**

Val, I'm curious to know what caused those compile errors. Are you using stable as opposed to nightly, and latest version?

What do you get with

Code: Select all

pi@raspberrypi:~/rust/rust_pi3d/pi3d $ rustup show
Default host: armv7-unknown-linux-gnueabihf
rustup home:  /home/pi/.rustup

stable-armv7-unknown-linux-gnueabihf (default)
rustc 1.39.0 (4560ea788 2019-11-04)

?

PS Also when I run Tim's raspberrypi code I get various issues (though it does compile ok) However using his more recent version Pi3C it compiles and runs without issues. Things like the depth bits are variables passed in on window creation. I will let him know that someone is interested in his code!

Posted: **Thu Nov 28, 2019 10:52 pm**

paddyg wrote: ↑
Thu Nov 28, 2019 12:31 pm
Val, I'm curious to know what caused those compile errors. Are you using stable as opposed to nightly, and latest version?

The errors were caused by the Raspbian cargo/rustc packages. I've removed them and installed rustup using the following command:

Code: Select all

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Now I get exactly the same version with "rustup show" as you, and everything works fine!
Nice demo, btw, and pretty fast too. I get 40-60fps with KMS.
The non-KMS setup shows 0.2 fps, but still it starts with no failure messages.

paddyg wrote: ↑
Thu Nov 28, 2019 12:31 pm
PS Also when I run Tim's raspberrypi code I get various issues (though it does compile ok) However using his more recent version Pi3C it compiles and runs without issues. Things like the depth bits are variables passed in on window creation. I will let him know that someone is interested in his code!

Thank you! Haven't noticed any issues with Tim's code so far. Among other things I did "sudo apt upgrade" yesterday which updated mesa libraries on my Buster. This could have fixed something.

Thanks,
Val.

Posted: **Thu Nov 28, 2019 11:20 pm**

Gavinmc42 wrote: ↑
Thu Nov 28, 2019 11:22 am
I don't use anything except fakeKMS on Pi4 Gentoo64.
Real KMS is still a work in progress one of the Pi guys said recently.
I set the shader version to 300 es.

I've seen Gentoo64 instructions for Pi3. Looks like some fussing around is needed to install it properly.
It also says analogue audio is untested. OpenGL seems a bit faster, though.
Anyway, not ready to give it a try at the moment... someday probably when I have more time on my hands.

Thanks,
V.

Raspberry Pi Forums

OpenGLES and Raspberry PI 3

OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3

Re: OpenGLES and Raspberry PI 3