2D objects invisible when VC4 driver used on Raspberry Pi #4
The VC4 driver for Raspberry Pi allows use of Mesa instead of Broadcom-specific GL APIs.
Firstly, Q3lite runs normally and as expected with the default Broadcom GL libraries. But I wanted to run Q3lite with the VC4 driver, so I did this by first configuring my system to use VC4, then modifying the Makefile like so:
Exactly how correct this approach was I'm unsure (having no GL experience whatsoever) but it at least compiled.
I ran it within an X11 session with the following parameters:
The game started, and I could see the map and walk around, but all 2D things were missing from the display, like my crosshair, health status, and the pull-down console.
I ran the game through
According to the documentation, it appears the
I've attached the apitrace file. I'm not sure how portable this file is, but it reproduces the graphical issue nicely on my laptop with Intel graphics:
As VC4 is the long-term future of graphics on the Raspberry Pi, using more standard components of the Linux graphics stack (Mesa, DRM, KMS), it will be good to get Q3lite working in this situation.
Thank you for your feedback. It’s very timely as I’m currently researching the steps necessary to add support for the OpenGL+KMS driver. If you haven’t seen it, I also have an open request for help in the Contributing Guide for implementing Mesa driver support. The renderer used in Q3lite was borrowed from another project, so I don’t have the expertise to make modifications to the renderer itself. However, I’m looking into adding the framework to allow switching renderers, which will make it more modular and easier for testing.
Another user mentioned that he compiled Q3lite for the Mesa driver (dtoverlay=vc4-kms-v3d), and that he had to replace -lGLESv2 with -lGLESv1_CM to fix linker errors (the Q3lite renderer uses OpenGL ES v1.1). He mentioned that the menus weren’t visible and the rendering was choppy at 1080P. You may also want to try without the -lGL and see if that makes a difference.
Any help and feedback that you can offer would be much appreciated. Thanks again.
Given so much has changed from Mesa 13 to Mesa 19 I gave this a try on my Pi 3B+ with Buster. Apparently it's fixed now (menus, crosshair, health status, and ~ pull-down console all render). This could be due to fixes in Mesa or one of the recent merges from ioq3 upstream.
I validated under both windowed mode in X11 and KMSDRM.
As @cdev-tux pointed out this is OpenGL ES 1.1, not 2.0, so the proper patch is:
Note that we retain
@jdonald Thank you for taking the time to look into this. I’ll be testing the code over the next few days on a fresh install of Buster, since my current install may have some added packages that are preventing things from working properly. I did find that SDL was attempting to use its RPI legacy driver on the Pi4, which won’t work so they have some updating to do as well. Thanks again for your time and effort.
I'm still having some issues getting this to run in X11. When you have time could you post a /condump from the game console so I can see the output of the game loading? Thanks.
Sorry for the delayed response.
By default, Raspbian compiles SDL2 with both rpi and x11 video support, but not kmsdrm. I expect they're going to keep
As for what's causing your issues: q3lite's build process appears to default to give the binary a linker path to a locally built SDL2 (
Sometimes I pass
To double-check that it's always calling the particular libSDL2.so (and other libraries) you're intending, I recommend often using the
Note that due to the excess use of
When running X11 in full screen the stdout text (not a condump, but gets the point across) has what you'd expect:
For testing kmsdrm, that isn't available in the default Raspbian install so I would build a local SDL2 with:
And of course occasionally check with
Thanks for your response. Setting
For testing I’ve been compiling the latest SDL2-2.0.10 and using that instead of the shared library installed by Q3lite. This can be done by setting the following in make-raspberrypi.sh.
In the past Q3lite hasn’t been able to use the SDL2 package in the Raspbian repo because that package is compiled to use X11 first, and the game hasn’t been using X11 for performance reasons. If SDL2 is compiled from source it places libs in
I came to the same conclusion as you about using sudo in the wrapper script. I plan to remove that code while I’m in there adding Pi 4 support.
Things are working in KMSDRM, although at a low framerate for now.
Thanks again for your help; that got me going in the right direction.