RasPi 4, failed to load driver: vc4

#1

I’m getting the following when running my oF app on Raspberry Pi 4 - with a fresh install of oF 0.11.0

libGL error: failed to create dri screen
libGL error: failed to load driver: vc4
libGL error: failed to create dri screen
libGL error: failed to load driver: vc4

/boot/config.txt has dtoverlay=vc4-fkms-v3d set for pi4

FWIW - everything seems to be working OK, but the same app on my pi3b+ runs with much less CPU. Pi4 seems to use way more CPU - esp. when I have an fbo.
(both have dtoverlay=vc4-fkms-v3d)

Any ideas?

#2

Hi!

For the speed issue there was a setting change which meant we are defaulting to 4x FSAA by default where is on the 3 it was set to 0. See this merged PR which will be in the next release: https://github.com/openframeworks/openFrameworks/pull/6503/files

For the GL errors see the notes here:
https://openframeworks.cc/setup/raspberrypi/raspberry-pi-getting-started/

> For openFrameworks 0.11.0 and onwards OF needs to use the new experimental GL driver instead of the legacy driver.
**> **
> 1. Select 7 Advanced Options and hit Enter
> * Select either GL Driver Fake KMS or GL Driver Full KMS or from the options and hit Enter

But it sounds like you are doing that already?

I hope the FSAA speed things up for you though,
Theo

#3

yeah GL Driver Fake KMS is already selected.

I thought I’d done that FSAA change previously. I’ll do it again and re-test… No significant change unfortunately.

on the vc4 error I found this page with some troubleshooting info and it tells me I’m using llvmpipe and not vc4 for some reason. unfortunately the info they provide for fixing that does not work for me (I dont have the 99-fbturbo.conf file)

EDIT - Hardware acceleration seems to be there, but it’s not getting used when I start the oF app with X11

Is this information useful? (from here)

The Pi 4 features an upgraded VideoCore VI GPU clocked at 500Mhz by default and comes with GLES 1.1, 2.0 and 3.0 support and in addition, X11 is now the window manager used by default using the Fake KMS kernel driver.

Trying my already tested Pi 3B+ setup for ET: Legacy using full OpenGL works exactly the same on the Pi 4; the game works well in X11, and there is still an issue running the game in fullscreen mode. GLES support however does not work and this is mainly due to the fact that the libbrcmGLESv2 library should no longer be linked to when compiling your GLES programs as that is for the legacy dispmanx driver. Instead, the GLESv1_CM Mesa library found within /usr/lib/ should be linked to. I also came across another problem too - libgles1-mesa-dev is not available in Raspbian Buster, Debian appear to have dropped support for the GLES 1.1 headers, this means that you need to use the firmware ones found within /opt/vc/include . I’ve been told that this isn’t technically the correct way of doing things, but as it currently stands, I’m not aware of any other way of getting the correct headers without a custom build of Mesa.

#4

Did you install the dependancies in:
openFrameworks/scripts/linux/debian/install_dependencies.sh

I am pretty sure when we were testing for 0.11.0 I was getting full Hardware Acceleration on RPi4 with the examples. ( Didn’t see any of those errors you mentioned ).

I was about to point you to the ofxRpi4Window addon here but see you already were in that thread. :slight_smile:

Are you using that window or the stock GLFW one?

#5

yeah - i’ve just finished a completely new build. installed dependencies and codecs.

Still getting the same errors. I wonder if its something with addons?

I’m going to go and try some various examples and see what happens.

ofxRpi4Window is maybe my next try after that.

not sure what you mean about stock window or stock GLFW.

running my app with startx ./bin/eyesy -- -s off

EDIT:

running graphicsExample - same problem

pi@eyesy:~/openFrameworks/examples/graphics/graphicsExample $ DISPLAY=0:0 startx ./bin/graphicsExample – -s off

X.Org X Server 1.20.4

X Protocol Version 11, Revision 0

Build Operating System: Linux 5.4.0-54-generic armv8l Raspbian

Current Operating System: Linux eyesy 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l

Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1024x600M@60 smsc95xx.macaddr=DC:A6:32:13:02:1C vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=ad546c01-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Build Date: 01 December 2020 05:59:57PM

xorg-server 2:1.20.4-1+rpt2+deb10u2 (https://www.debian.org/support)

Current version of pixman: 0.36.0

Before reporting problems, check http://wiki.x.org

to make sure that you have the latest version.

Markers: (–) probed, (**) from config file, (==) default setting,

(++) from command line, (!!) notice, (II) informational,

(WW) warning, (EE) error, (NI) not implemented, (??) unknown.

(==) Log file: “/var/log/Xorg.0.log”, Time: Fri Jan 8 20:10:36 2021

(==) Using system config directory “/usr/share/X11/xorg.conf.d”

(II) modeset(0): Initializing kms color map for depth 24, 8 bpc.

libGL error: failed to create dri screen

libGL error: failed to load driver: vc4

libGL error: failed to create dri screen

libGL error: failed to load driver: vc4

#6

aha - seems like if I run startx from a directly attached console it does not throw the libGL errors - but if I startx from ssh with DISPLAY=0:0 startx ./bin/graphicsExample -- -s off then it has the errors.

same goes for starting from a systemctl unit - which is my end goal.

EDIT:
Looks like I am able to get the systemd unit to startx properly if I remove the user/group that I had previously set there.

X permissions issue somewhere I guess causing it to use the wrong driver? Crazy.

#7

If you don’t have a display and still want to use OpenGL operations using xvfb can be a workaround - see the very end of this page: https://openframeworks.cc/setup/raspberrypi/raspberry-pi-getting-started/

But I think the ofxRpi4Window add-on will give you the most flexibility as I believe it doesn’t require X to be present or a display and still allows OpenGL ( I think its the most similar to the old approach that works on Rpi 3)