OpenGL WITHOUT X/GUI?

[trithilon]

OpenGL WITHOUT X/GUI?

I am building a microconsole using an RPi0 2W and an HDMI touch screen.

The project needs super-fast boot up time ( <5 sec - piCore shines!) and render PS1/n64 level graphics.
AFAIK, you need a GUI desktop to run most 3D applications. Adding GUI significantly increases start-up time.

As I don't need multitasking, I am thinking of using SDL1.2 to build my own games which can use GLES2 on the VC4 GPU and draw directly to /dev/fb0.

Is this even possible? Am I in the right direction?

P.S. It would be wonderful to see a solution which can also run ANY app in a single app/fullscreen mode from the command line (for eg. glxgears).

[curaga]

Yes, GLES on FB is possible. You should be aware though that GL ES is different from desktop OpenGL, it's much more limited.

Glxgears uses GLX like the name says, meaning it requires X. You can run a single X app instead of a WM by editing .xsession. To get it fullscreen, you'd use the app's arguments (-geometry etc) if it supports those.

[Rich]

Hi trithilon

... To get it fullscreen, you'd use the app's arguments (-geometry etc) if it supports those.

And if it doesn't, you can try  Resizer:
http://forum.tinycorelinux.net/index.php/topic,25125.0.html
Also see the update in Reply #6.

It does not currently exist for ARM but the source package can be found here:
http://tinycorelinux.net/12.x/x86/tcz/src/Resizer/

To build it:

Code: [Select]

wget http://tinycorelinux.net/12.x/x86/tcz/src/Resizer/Resizer-source-v0.20.tar.gz
tar xf Resizer-source-v0.20.tar.gz
cd Resizer
./CompileResizerThe  CompileResizer  script compiles and creates the  Resizer.tcz  files.

[trithilon]

I am trying out Raylib instead of SDL, seems raylib has a native DRM mode for raspberry pi for command line graphics. Guessing will need libdrm.
https://github.com/raysan5/raylib/wiki/Working-on-Raspberry-Pi
I'll post my findings.

Yes, GLES on FB is possible. You should be aware though that GL ES is different from desktop OpenGL, it's much more limited.

Glxgears uses GLX like the name says, meaning it requires X. You can run a single X app instead of a WM by editing .xsession. To get it fullscreen, you'd use the app's arguments (-geometry etc) if it supports those.

Ah got it. Just to be clear, you mean editing .Xsession to run one application in kiosk mode (pointing X to an app and NOT a WM)?

Hi trithilon

... To get it fullscreen, you'd use the app's arguments (-geometry etc) if it supports those.

And if it doesn't, you can try  Resizer:
http://forum.tinycorelinux.net/index.php/topic,25125.0.html
Also see the update in Reply #6.

It does not currently exist for ARM but the source package can be found here:
http://tinycorelinux.net/12.x/x86/tcz/src/Resizer/

To build it:

Code: [Select]

wget http://tinycorelinux.net/12.x/x86/tcz/src/Resizer/Resizer-source-v0.20.tar.gz
tar xf Resizer-source-v0.20.tar.gz
cd Resizer
./CompileResizerThe  CompileResizer  script compiles and creates the  Resizer.tcz  files.

Thanks! You saved me one more thread. I'll try this out.

[curaga]

Ah got it. Just to be clear, you mean editing .Xsession to run one application in kiosk mode (pointing X to an app and NOT a WM)?

Yes. 3d apps don't really need a WM, but a browser or similar that pops up "save to" dialogs might.

[CNK]

I am trying out Raylib instead of SDL, seems raylib has a native DRM mode for raspberry pi for command line graphics.

Maybe you're already aware, but SDL2 has a "KMS/DRM" driver as well.

[Juanito]

SDL2 extension updated in case you decide to go that way.

Edit: You can play a video from the console with "SDL_VIDEODRIVER=kmsdrm ffplay video.mp4", so I presume using sdl2 directly would work.

[trithilon]

Something interesting happened.
I compiled raylib in native RPI mode (no X11) it worked with just one package - rpi-vc-dev.tcz.
You will get a vchiq* error which you can fix by running: sudo chmod 777/dev/vchiq
The key is sticking to Legacy GL drivers and NOT forcing VGA or a certain HDMI mode.

Alternatively, I can load Xorg-3d package to enable DRM (no-X11) and then run the DRM mode of raylib.
On DRM, I get better FPS for full screen effects.
But on native RPI (I think it talks directly to the VC4) its able to do better FPS on lights.
Both non-X11 modes struggle with Bunnymark (~2000 for 60fps).

But, with X11 my Bunnymark scores are twice as high (4000 for 60 fps).
Why is the same hardware performing so differently?

SDL2 extension updated in case you decide to go that way.

Edit: You can play a video from the console with "SDL_VIDEODRIVER=kmsdrm ffplay video.mp4", so I presume using sdl2 directly would work.

Wow thanks. Been tinkering with raylib. SDL is my fallback.

I am trying out Raylib instead of SDL, seems raylib has a native DRM mode for raspberry pi for command line graphics.

Maybe you're already aware, but SDL2 has a "KMS/DRM" driver as well.

Yeah, I am trying to get it to work without DRM because my goal is to avoid long loading times for extensions. Xorg-3D will really add a good 10 seconds. My goal is ~5-6 seconds of boot time if I can by pass DRM.

Thanks for all the help folks!

[CNK]

Something interesting happened.
I compiled raylib in native RPI mode (no X11) it worked with just one package - rpi-vc-dev.tcz.
You will get a vchiq* error which you can fix by running: sudo chmod 777/dev/vchiq
The key is sticking to Legacy GL drivers and NOT forcing VGA or a certain HDMI mode.

Alternatively, I can load Xorg-3d package to enable DRM (no-X11) and then run the DRM mode of raylib.
On DRM, I get better FPS for full screen effects.
But on native RPI (I think it talks directly to the VC4) its able to do better FPS on lights.
Both non-X11 modes struggle with Bunnymark (~2000 for 60fps).

But, with X11 my Bunnymark scores are twice as high (4000 for 60 fps).
Why is the same hardware performing so differently?

It probably means that the DRM drivers are simply more efficient than the proprietary Broadcom drivers in rpi-vc-dev.tcz. This summary at the Raspberry Pi forums has more details, but the broadcom library and DRM-based libraries seem to be the only options for accelerated OpenGL.

Better performance on X11 is odd, it should be using Mesa, which I presume is what raylib uses in its direct DRM mode. Maybe raylib has some slow OpenGL code which is bypassed in X11 mode and faster Xorg code is then used instead? That might be most likely if it's using GLX in X11 mode rather than EGL. But I'm guessing.

[trithilon]

Something interesting happened.
I compiled raylib in native RPI mode (no X11) it worked with just one package - rpi-vc-dev.tcz.
You will get a vchiq* error which you can fix by running: sudo chmod 777/dev/vchiq
The key is sticking to Legacy GL drivers and NOT forcing VGA or a certain HDMI mode.

Alternatively, I can load Xorg-3d package to enable DRM (no-X11) and then run the DRM mode of raylib.
On DRM, I get better FPS for full screen effects.
But on native RPI (I think it talks directly to the VC4) its able to do better FPS on lights.
Both non-X11 modes struggle with Bunnymark (~2000 for 60fps).

But, with X11 my Bunnymark scores are twice as high (4000 for 60 fps).
Why is the same hardware performing so differently?

It probably means that the DRM drivers are simply more efficient than the proprietary Broadcom drivers in rpi-vc-dev.tcz. This summary at the Raspberry Pi forums has more details, but the broadcom library and DRM-based libraries seem to be the only options for accelerated OpenGL.

Better performance on X11 is odd, it should be using Mesa, which I presume is what raylib uses in its direct DRM mode. Maybe raylib has some slow OpenGL code which is bypassed in X11 mode and faster Xorg code is then used instead? That might be most likely if it's using GLX in X11 mode rather than EGL. But I'm guessing.

Seems X11 only gives better performance when there are more objects to be drawn (like textures_bunnymark (8k bunnies) or models_waving_cubes 3300+ cubes)
I did exhaustive testing on a Pi02W, you can see my results with different combinations:
https://1drv.ms/x/s!ArJ1qYI1SjsMj9sNuQ8Xd0JTbe6usg?e=Do6iyj