guide: libsdl, dosbox, vice with hw acceleration

[riq]

Hi,

Here is a detailed guide that explains how to have libSDL + GLES2 (hardware accelerated), and some popular emulators that uses SDL like DOSBox and VICE on Odroid C4.
https://gitlab.com/ricardoquesada/odroi ... /kmsdrm.md

Let me know of you it doesn't work for you.

Thanks @tobetter for the help.

[tobetter]

Did you make any chance on the SDL code? Or just run as-is after compiling?
I also wonder if the SDL can run on top of Wayland as well.

[riq]

I used an unmodified version of SDL (compiled as described on the guide), and works Ok using KMS/DRM backend.

When SDL is using GLES2 hardware accelerated, it doesn't work using Wayland backend. Tested on Weston.
It doesn't crash, it seems that EGL is initialized correctly, but it fails to create a new window.

When SDL is compiled without hw-accel, then it works Ok using Wayland backend.

[meveric]

be careful with DOSBox though.
DOSBox does no know GLESv2 it only knows OpenGL.
It runs due to the fact that the default simply uses Surface or Overlay as a backend without the need of OpenGL support.
If you switch in the config to OpenGL it will probably fail, due to the fact that OpenGL is not part of the SDL2 package.
This also means DOSBox doesn't run on Hardware Acceleration, it uses SDL2, nothing more.

[AreaScout]

Looks great, but I doubt that it will run on GBM (but I pray it does), are you sure SDL2 doesn't choose Wayland here, it would also be cool to show the first lines from the command line to prove that the right renderer is chosen

RG

[riq]

thanks @meveric, guide updated.

@AreaScout: Not sure I got your question correctly, but I confirm that when I run `testgles2` in Weston, it was using the Wayland backend (I debugged it).
But it doesn't work. I couldn't go much deeper than knowing that EGL was correctly initialize. But besides that, I don't know what's happening (didn't have time).
That's for Wayland.

KMS/DRM works without any problem (hw-accel).

[tobetter]

I've rebuilt the modified SDL with '--enable-video-kmsdrm --disable-video-opengl --enable-video-wayland', and it looks sort of working.

Code: Select all

$ SDL_VIDEODRIVER=wayland ./testdisplayinfo
INFO: Using video target 'wayland'.
INFO: See 1 displays.
INFO: 0: "2369M" (1920x1080, (0, 0)), 1 modes.
ERROR:     DPI: failed to query (That operation is not supported)
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=60
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=60
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=60
INFO:

Two SDL2 test apps running on Gnome Desktop.

Screenshot from 2020-05-12 02-58-23.png (818.77 KiB) Viewed 433 times

[riq]

nice! (I should double-check everything again). And ft it keeps non-working, I should try it on gnome+wayland instead of Weston.

[AreaScout]

@riq

No I was under the impression that SDL2 was choosing Wayland video driver internally instead of GBM KMS/DRM, if that is working the C4 could jump some ranks up on my favorite sbc board hit list, but how ? KMS/DRM backend is highly interfering with libdrm but there is no supported HW backend for meson in libdrm ?? So I am curious ...

RG

[riq]

@AreaScout

This is my understanding (probably @tobetter knows better):

I'm using the mali-bifrost-wayland-driver for hw-accel in KMS/DRM. But the name could be misleading. This driver installs the "libmali.so" driver, which offers an implementation of: EGL, GLES2 and GBM (among other things). So buffers and rendering are done by this library.
This driver could be used by Wayland as well by KMS/DRM.
When using SDL2 with KMS/DRM the rendering is deletaged to this libmali.so, but the scanout is done by KMS/DRM (which I think uses the meson driver).

Does it makes sense?

[AreaScout]

@AreaScout

This is my understanding (probably @tobetter knows better):

I'm using the mali-bifrost-wayland-driver for hw-accel in KMS/DRM. But the name could be misleading. This driver installs the "libmali.so" driver, which offers an implementation of: EGL, GLES2 and GBM (among other things). So buffers and rendering are done by this library.
This driver could be used by Wayland as well by KMS/DRM.
When using SDL2 with KMS/DRM the rendering is deletaged to this libmali.so, but the scanout is done by KMS/DRM (which I think uses the meson driver).

Does it makes sense?

Well your explanation is mostly right but SDL2 KMS/DRM backend is using the libdrm API to talk to the kernel DRM driver, upstream libdrm does not have support for Amlogic meson other then the build system with the same name and here are the supported GPU vendors https://cgit.freedesktop.org/mesa/drm/tree/

Samsung Exynos, Intel, Texas Instrument, Radeon, Nvidia, Raspberry etc. but no Amlogic, Rockchip has it's own implementation of libdrm and is hosted here https://github.com/rockchip-linux/libdrm-rockchip, so either there is a custom libdrm used or SDL2 is using Wayland or SDL2 is falling back to mesa software rasterizer and that's why I asked for the gles render string that you get when you start the testgles2 tool

RG

[AreaScout]

@riq

Ok today I got finally my C4 board, I tested your tutorial but there are mesa libraries installed and so it fails on KMSDRM and wayland, so I fixed the symbolic links manually to point to libmali.so instead of mesa and now the testgles2 example works hardware accelerated, I was a little surprised that it works because I don't know exactly how and what route it takes internally, but I will find out. Also the permissions on /dev/dri/card0 was wrong and I got a permission denied error.

RG

[riq]

@AreaScout what ubuntu image did you install? the instructions that I wrote are based on the "ubuntu-minimal" image.

[AreaScout]

@riq

No I was installing Windows 10 image Of course it was that one http://ppa.linuxfactory.or.kr/images/ra ... 421.img.xz

RG

[tobetter]

I've made a test package libsdl2-2.0-0 which has my patches to run on ODROID-C4/N2, I've tested with a couple of simple test apps on terminal using 'KMSDRM' display driver and Gnome Desktop using 'wayland'. On Gnome Desktop, SDL app will just run using 'wayland' without SDL_VIDEODRIVER=wayland.

Code: Select all

$ sudo apt update
$ sudo apt install libsdl2-2.0-0 libsdl2-dev
$ dpkg -l | grep sdl
ii  libsdl2-2.0-0:arm64                        2.0.10+dfsg1-3+202005122340~focal          arm64        Simple DirectMedia Layer
ii  libsdl2-dev:arm64                          2.0.10+dfsg1-3+202005122340~focal          arm64        Simple DirectMedia Layer development files

[riq]

tobetter@ thanks for creating the compiled libs!

I've just tried both on C4 and N2 using the minimal ubuntu image.

On N2:

On N2 + Wayland it works Ok.
On N2 + KMSDRM it works Ok with a few "nits":

"testdisplayinfo" reports only one mode in KMSDRM:

Code: Select all

INFO: Using video target 'KMSDRM'.
INFO: See 1 displays.
INFO: 0: "0" (1920x1200, (0, 0)), 1 modes.
ERROR:     DPI: failed to query (That operation is not supported)
INFO: CURRENT: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1200 refresh=60
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1200 refresh=60
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1200 refresh=60
INFO: 

On Wayland, it reports all the modes:

Code: Select all

INFO: Using video target 'wayland'.
INFO: See 1 displays.
INFO: 0: "S2719DGF" (1920x1200, (0, 0)), 20 modes.
ERROR:     DPI: failed to query (That operation is not supported)
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO:     MODE 1: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=60
INFO:     MODE 2: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=59
INFO:     MODE 3: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=50
INFO:     MODE 4: fmt=SDL_PIXELFORMAT_RGB888 w=1680 h=1050 refresh=59
INFO:     MODE 5: fmt=SDL_PIXELFORMAT_RGB888 w=1600 h=1200 refresh=60
INFO:     MODE 6: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=1024 refresh=75
INFO:     MODE 7: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=1024 refresh=60
INFO:     MODE 8: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=800 refresh=59
INFO:     MODE 9: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=720 refresh=60
INFO:     MODE 10: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=720 refresh=59
INFO:     MODE 11: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=720 refresh=50
INFO:     MODE 12: fmt=SDL_PIXELFORMAT_RGB888 w=1152 h=864 refresh=75
INFO:     MODE 13: fmt=SDL_PIXELFORMAT_RGB888 w=1024 h=768 refresh=75
INFO:     MODE 14: fmt=SDL_PIXELFORMAT_RGB888 w=1024 h=768 refresh=60
INFO:     MODE 15: fmt=SDL_PIXELFORMAT_RGB888 w=800 h=600 refresh=75
INFO:     MODE 16: fmt=SDL_PIXELFORMAT_RGB888 w=800 h=600 refresh=60
INFO:     MODE 17: fmt=SDL_PIXELFORMAT_RGB888 w=720 h=576 refresh=50
INFO:     MODE 18: fmt=SDL_PIXELFORMAT_RGB888 w=720 h=480 refresh=59
INFO:     MODE 19: fmt=SDL_PIXELFORMAT_RGB888 w=640 h=480 refresh=75
INFO: 

And "testgles2", on KMSDRM runs limited by vsync, but on Wayland it runs at max speed.
I haven't seen these behaviors when I compiled libsdl myself.

On C4:

On Wayland: It works Ok.
On KMSDRM I got:
ERROR: Couldn't initialize SDL: No available video device

I tried
- upgrading to 5.7
- starting from scratch with a clean image
- reinstalling mali-wayland-dkms + reboot

But I'm still getting that error.

My wild guess is that it not using libmali.so. I don't understand who/how decides which library should be loaded in runtime.
If you could give any pointers, I might be able to debug the issue. Thanks.

UPDATE:
It would be great to add libdrm-dev, libgbm-dev, libegl-dev, libgles-dev as dependencies for libsdl2-dev.

[tobetter]

@riq, I've updated two packages, 'mali-bifrost-wayland-driver' and 'libsdl2-2.0-0'. I also faced the same issue on ODROID-C4 after a new installation and observed something different behaves installing the packages between Netboot Installer and preinstalled image. Anyway, after updating the two packages, KMSDRM issue on ODROID-C4 would be resolved.

[riq]

thanks!.
I confirm that it works Ok both on N2 and C4; and both on Wayland and KMSDRM (with the limitation that on KMSDRM only one mode seems to be available).

[tobetter]

thanks!.
I confirm that it works Ok both on N2 and C4; and both on Wayland and KMSDRM (with the limitation that on KMSDRM only one mode seems to be available).

Very quick...Thank you for the testing...then...what's next? LoL

"Tapatalk wishes you to have fun with ODROID"

[riq]

Very quick...Thank you for the testing...then...what's next? LoL

since you asked
Perhaps you know how to fix it (or if you don't, you might know where I can file a bug), and is drm-atomic.

On N2, it seems that the Android_explict_sync[1] extension is not present, so you cannot run "kmscube -A" (atomic + android sync extension).
On C4, that extension is present, but when you run "kmscube -A" after a few seconds, it will abort saying there was a bug with a fence.

Ideally, both N2 and C4 should have the Android-explicit-sync extension.
And ideally, "kmscube -A" should run fine.

This is because, in a future, (and assuming I have time), I'd like to add drmAtomic to SDL (currently it is using "legacy").

[1]: https://www.khronos.org/registry/EGL/ex ... e_sync.txt