[Solved] Installing on a Pi4?

[bomblord]

Hello all, I've somewhat recently picked up a pi 4 and after a cursory google search found people managing to install openmw as far back as the Pi2. Getting excited I decided to look into how to do this and after a lot of googling I found.... nothing on the pi4. I did find some limited info on the pi 3 and the instructions looked promising but seems to put me into "dependency hell" by force adding an old apt repository and disabling several safety checks.

Deciding that those instructions were bunk I began investigating just compiling it myself. I tried just compiling from Github but that just throws a generic "make error 2" about 10% of the way in. I looked into download options I noticed several 64 bit arm versions available but I can't find anything newer for armhf (Raspbian Buster is FRUSTRATINGLY 32 bit Armv7l despite running on an armv8 processor and having 4GB of RAM) I did attempt to run an older .deb package of an armhf (v40.0.2) build but that just throws a large number of dependency errors.

So I'm curious if installing openmw on the pi 4 is even possible at this point? Would I be better off waiting for a linux flavor to release for it that supports a 64 bit userspace?

[bomblord]

Got it installed but now I get a pink screen with garbled audio. Any assistance would be appreciated

[psi29a]

First thing first, you gotta enable the VC4 (rpi2~3) or VC5 (rpi4) drm. Normally you can do this with a fresh raspbian install then do rpi-config and drill down through the options. Once that is done, bring up X (not wayland) and validate you are running VC4/5:

glxinfo | grep -i VC

If you don't get a result, you're going to have a bad day. What it will be doing is running all OpenGL calls through LLVM (softpipe) which will take an age to render.

Next step will be to build/compile your own version of OSG. Sadly OSG maintainers were bullied by Ubuntu to only build support for OpenGLESv2/3, not OpenGL itself, for armhf/armle arches. That means trying to run OpenMW with standard osg-3.4 is going to give you pink-eye if it runs at all. OpenMW needs, at least, OpenGL 2.1 to run. You might be able to work around this with a shim that translate OpenGL calls to GLESv2/v3 equivalents like the Android port, but that is an imperfect solution.

You might get lucky here... I made OSG-3.4 that should run on armhf/armel and only uses OpenGL (not GLES):
https://launchpad.net/~openmw/+archive/ ... /+packages

They were built with Ubuntu in mind though, so try older (Trusty) debs first and see if that works. If not, then you'll need roll OSG yourself. Good luck! :

[bomblord]

First thing first, you gotta enable the VC4 (rpi2~3) or VC5 (rpi4) drm. Normally you can do this with a fresh raspbian install then do rpi-config and drill down through the options. Once that is done, bring up X (not wayland) and validate you are running VC4/5:

glxinfo | grep -i VC

If you don't get a result, you're going to have a bad day. What it will be doing is running all OpenGL calls through LLVM (softpipe) which will take an age to render.

Next step will be to build/compile your own version of OSG. Sadly OSG maintainers were bullied by Ubuntu to only build support for OpenGLESv2/3, not OpenGL itself, for armhf/armle arches. That means trying to run OpenMW with standard osg-3.4 is going to give you pink-eye if it runs at all. OpenMW needs, at least, OpenGL 2.1 to run. You might be able to work around this with a shim that translate OpenGL calls to GLESv2/v3 equivalents like the Android port, but that is an imperfect solution.

You might get lucky here... I made OSG-3.4 that should run on armhf/armel and only uses OpenGL (not GLES):
https://launchpad.net/~openmw/+archive/ ... /+packages

They were built with Ubuntu in mind though, so try older (Trusty) debs first and see if that works. If not, then you'll need roll OSG yourself. Good luck! :

Sorry, I guess I should be more specific (that's my fault) in order to get it installed I've installed a community build of Gentoo 64. I'm now running an armv8 64 bit userspace and environment so no need for armle or armhf. Any raspbian/debian instructions are more than likely not available either (definitely so in the case of using raspi-config). I also don't believe it's possible to install Debian packages on this so that repository doesn't work for me..

When I run a glxifno with a grep version this is the result

Code: Select all

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL version string: 2.1 Mesa 19.1.4
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Which seems to be at your 2.1 minimum

[psi29a]

Can you do a grep -i vendor please?

It should say VC5 (or VC4 or something VC).

That is important otherwise you'll get a slideshow. If you get something like SGI or LLVM... then you're going to have a bad day.

[bomblord]

Can you do a grep -i vendor please?

It should say VC5 (or VC4 or something VC).

That is important otherwise you'll get a slideshow. If you get something like SGI or LLVM... then you're going to have a bad day.

Code: Select all

glxinfo | grep -i vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: Broadcom (0x14e4)
OpenGL vendor string: Broadcom

Looks like I'm going to have a bad day

[AnyOldName3]

I'm confused. If it's saying Mesa and Broadcom, wouldn't it mean it's running on the GPU?

[psi29a]

I'm not sure actually... with RPi 1, 2, 3... it always said VC4. Things might be different now with VC5 on RPi4.

[bomblord]

I'm not sure actually... with RPi 1, 2, 3... it always said VC4. Things might be different now with VC5 on RPi4.

Videocore VI is what's in the Pi 4.

[psi29a]

Okay.. VC6 then Anyway, Can you post the full output of glxinfo please?

Regardless, the real issue is OSG. You need to make sure it is compiled for desktop GL and not GLES.

When you run openmw though, do you see anything in the console or log file?