Thread from Pi4 discussion

[6by9]

I thought the VC4 did support linear textures... (Quick read of docs)... Ah, not totally linear, just that you can have the micro-tiles in linear order rather than snaking.

I think it does support them, but there was a bug where the width has to be a power of two. Iirc Raspivid rendering to 3d used raster order buffers, or certainly the isp isn't producing t-format.

[Solskogen]

I would suggest you configure SDL2 with --disable-video-rpi --enable-video-kmsdrm as options. Unless you do, SDL2 gets configured with the old rpi driver in /opt/vc. And with --enable-video-kmsdrm you can use SDL2 in console, without X11. kmsdrm needs a couple of packages installed: libgdm-dev and libdrm-dev.

[Arkiruthis]

I would suggest you configure SDL2 with --disable-video-rpi --enable-video-kmsdrm as options. Unless you do, SDL2 gets configured with the old rpi driver in /opt/vc. And with --enable-video-kmsdrm you can use SDL2 in console, without X11. kmsdrm needs a couple of packages installed: libgdm-dev and libdrm-dev.

Thank you! I came here to ask this very question as I'm migrating a project from Pi 2 to Pi 4 and I'm using my own SDL2 installation.

[techyian]

Thanks Solskogen, will try this out! Is anyone aware of anyway to check the host is a Pi 4? /proc/cpuinfo states an incorrect model number for the Broadcom CPU (I've read the thread explaining why) - I've been told you can do bitwise operations on the revision number to get out the correct info, is this the only solution? I have a CMake script which is currently checking for the "bcm_host.h" header and if that exists, the host is a Pi and that works well. However due to the differences in a Pi 4 for GLES and SDL I will need some way of detecting specifically for a Pi 4. Any ideas?

[jamesh]

Thanks Solskogen, will try this out! Is anyone aware of anyway to check the host is a Pi 4? /proc/cpuinfo states an incorrect model number for the Broadcom CPU (I've read the thread explaining why) - I've been told you can do bitwise operations on the revision number to get out the correct info, is this the only solution? I have a CMake script which is currently checking for the "bcm_host.h" header and if that exists, the host is a Pi and that works well. However due to the differences in a Pi 4 for GLES and SDL I will need some way of detecting specifically for a Pi 4. Any ideas?

If you don't want to parse the revision code (which is the best way IMO)

cat /proc/device-tree/model

[Solskogen]

Oh, quick note. I cannot get SDL 2.0.9 to work. I had to use the one in mercurial (the coming 2.0.10 version)

[techyian]

@jamesh thank you, using cat /proc/device-tree/model worked a treat.

One final question that seems specific to Pi 4 & X11, when playing Enemy Territory and moving the mouse quickly to the left will cause the desktop mouse cursor to show in-game for a brief moment and that causes any movement to stop until you try moving again. On the Pi 3, full OpenGL and GLES work great which is why I think this is a X11 problem.

I've come across a few posts online where this has happened to people in the past but it was a long time ago and their suggestions don't work unfortunately.

I'm not a games developer but it would be great to fix this on the Pi 4. The version of Enemy Territory I'm using has an SDL 2.0.9 backend. Has anyone ever come across an issue like this before? Full screen mode doesn't help in this case.

Thanks!

[Arkiruthis]

Following Solskogen's suggestions I built the latest SDL with kmsdrm and was able to get my game running fine with OpenGL ES 3.0. It works fine in console mode, but in X11 I get a buffer error (which I think makes sense, as I've not compiled SDL for X11?). UPDATE - works fine in X11 as well.

It certainly seems to run at a decent speed and the output seems encouraging.

Code: Select all

INFO: GL SwapInterval (vsync) : 1
INFO: Window: 1920, 1200
INFO: Renderer: 1920, 1200
INFO: Logical: 0, 0
INFO: Using GL Renderer: V3D 4.2
INFO: Using OpenGL version: OpenGL ES 3.0 Mesa 19.1.0-devel
INFO: Using Vendor: Broadcom
INFO: Using GLSL version: OpenGL ES GLSL ES 3.00
INFO: ------------> 8192, 8192
INFO: MAX TEXTURE SIZE: 8192

One difference though, I think there was possibly a typo? I had to install libGBM, not libGDM? Only reason I mention it is that when running "configure" on SDL I noticed it said LIBGBM: NO but no mention of libGDM. Unfortunately my knowledge of these packages is not extensive.

Just for completeness, here were the build options for SDL that worked for me (works in both console and X11):

Code: Select all

../configure --disable-video-rpi --enable-video-kmsdrm --enable-video-x11 --disable-video-opengl

[techyian]

@Arkiruthis unfortunately I receive "KMSDRM not available" when I try to run Enemy Territory in console mode. To force the KMSDRM driver, I ran:

Code: Select all

SDL_VIDEODRIVER=kmsdrm ./etl

Not sure why this is happening. I ran the configure command you put in your post and whilst configuring .

Code: Select all

checking for LIBDRM... yes
checking for LIBGBM... yes
checking for kmsdrm dynamic loading support... yes

Video drivers   : dummy x11(dynamic) kmsdrm(dynamic) opengl_es2 vulkan

This would suggest that all the pre-requisites are installed and the kmsdrm driver can be used. Could there be something I've missed or does there need to be some specific SDL code used within the game itself to use KMSDRM? Using SDL 2.0.10 from mercurial.

[jdonald]

techyian: KMSDRM always works as expected for me too. I usually test with MrBoom (sudo apt install mrboom). I'm using a Pi 3B+ as I don't have a Pi 4 yet.

The main ways I suspect this could fail for you are:
* You had been running in Legacy mode instead of fkms; or
* You're inadvertently linking the system libSDL2.so instead of your compiled one. In my flow I leave the system one intact, but typically compile+install to /usr/local and run with LD_LIBRARY_PATH=/usr/local/lib SDL_VIDEODRIVER=kmsdrm mrboom. You can double-check that it's linking properly by putting ldd in your command; or
* Maybe something really is different with this mode on the Pi 4, although I hope not.

You do not require any specific SDL code within the game itself to use KMSDRM.

[techyian]

Thank you for that @jdonald, I will have another look with KMSDRM this evening and report back.

[techyian]

@jdonald - I've got a bit further following your advice and the next error message I get is "Could not create EGL window surface", this occurs when trying both full OpenGL and GLES.

[jdonald]

Odd. EGL is intended only for interacting with a display manager like X11 or Wayland, or so I thought. With direct rendering, in theory nothing should ever call eglCreateWindowSurface() because there's no window.

I assume you configured with --disable-video-x11. Perhaps you installed Wayland libraries at some point and need to explicitly add --disable-video-wayland? Anything strange appearing in the configure output?

Do you get the same result with your own program as well as third-party apps like mrboom? That'll at least narrow down whether the issue is something specific to your code vs your SDL2 build or system configuration.