How to turn on OpenGL on RPi 3B (Solved)

[jimcuclamath]

I have a Raspberry Pi 3B running openSUSE-release-20180910 (Tumbleweed). I ran GLMark2 with dtoverlay=vc4-kms-v3d in extraconfig.txt, with dtoverlay=vc4-fkms-v3d, and with no GPU overlay. In each instance I got an overall score of 12. Compare to my laptop (Intel HD Graphics 5000, nothing special) which gets an overall score of 1747, and the individual tests mostly score about 100x what the RPi does. I don't expect the RPi to run that fast, but I'm concluding that I have no GPU acceleration at all.

/var/log/Xorg.0.log confirms (with dtoverlay=vc4-fkms-v3d):
Initializing extension GLX
AIGLX: Screen 0 is not DRI2 capable
IGLX: Loaded and initialized swrast
GLX: Initialized DRISWRAST GL provider for screen 0

Can someone please give me a clue as to the magic incantation to turn on GPU acceleration? Particularly, if there's a missing library, its name and the package providing it (and which distro) would be very helpful.

Possibly useful information:
Kernel command line:
BOOT_IMAGE=/boot/Image-4.18.8-1-default
root=UUID=edf0b932-eb7e-4c54-91be-fd7861e59783
loglevel=3 splash=silent plymouth.enable=0
swiotlb=512 cma=300M
console=ttyS1,115200n8 console=tty resume=/dev/mmcblk0p3

/boot/efi/config.txt (with comments removed and annotations added):
kernel=u-boot.bin #OpenSuSE hacked U-Boot to do EFI and load Grub
gpu_mem=32
force_turbo=0
initial_turbo=30
over_voltage=0
enable_uart=1
avoid_warnings=1
dtoverlay=upstream
dtoverlay=upstream-mmc
dtoverlay=upstream-aux-interrupt
[pi1]
arm_freq=840
core_freq=375
sdram_freq=400
[pi3]
dtoverlay=rpi3-hdmi
[all]
include ubootconfig.txt #Its content: arm_control=0x200
include extraconfig.txt
#Its content:
dtparam=audio=on
dtoverlay=vc4-fkms-v3d # or vc4-kms-v3d or nothing

Relevant looking modules in /proc/modules -- I can post the whole thing
if I've missed something.
vc4
drm_kms_helper
drm
vchiq
(and various sound drivers)

Relevant-looking userspace libraries and their packages:
/usr/lib64/libEGL_mesa.so.0.0.0 Mesa-libEGL1-18.1.7-208.1.aarch64
/usr/lib64/libEGL.so.1.1.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libGLdispatch.so.0.0.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libGLESv1_CM.so.1.2.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libGLESv2.so.2.1.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libGL.so.1.7.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libGLU.so.1.3.1 libGLU1-9.0.0-13.6.aarch64
/usr/lib64/libGLX_mesa.so.0.0.0 Mesa-libGL1-18.1.7-208.1.aarch64
/usr/lib64/libGLX.so.0.0.0 libglvnd-1.1.0-1.1.aarch64
/usr/lib64/libOpenGL.so.0.0.0 libglvnd-1.1.0-1.1.aarch64

libglvnd is a "Vendor-neutral dispatch layer for arbitrating OpenGL API calls between multiple vendors on a per-screen basis, as described by Andy Ritger's OpenGL ABI proposal."

The X-Server is /usr/bin/X -> Xorg from xorg-x11-server-1.20.1-1.1.aarch64 . /etc/X11/xorg.conf is absent, and /etc/X11/xorg.conf.d contains no jimc hacks and nothing else that seems relevant.

[Imperf3kt]

Open a terminal
Type sudo raspi-config
Find the display options, set the driver to option 1 or 2

Note, this feature is still experimental and causes some issues with other parts of your system.

[jimcuclamath]

@Imperf3kt, thank you for pointing me on the right track. I bought another memory card and put Raspbian (Stretch) on it as a positive control. Using raspi-config G7-Advanced A7-OpenGL, I selected 2-Fake KMS. I couldn't find a .deb package for GLMark2, but I did find and install globs-0.2.0~svn50-4 . With dtoverlay=vc4-fkms-v3d, framerates were all about 60fps, limited by vertical refresh. With legacy GL, framerates were pathetic, ranging from 0.4 to 3.2fps. So GPU acceleration is working. The next step is to get it working in OpenSuSE Tumbleweed.

However, I didn't make much progress there.
1. I installed Mesa-dri-vc4-18.1.7-208.1.aarch64.rpm providing vc4_dri.so .
2. I did by hand what raspi-config does for Raspbian: dtoverlay=vc4-fkms-v3d was already there. config.txt has gpu_mem=32 and in extraconfig.txt I suppressed this with gpu_mem= (no value).
3. In the kernel command line I removed splash=silent plymouth.enable=0 but I kept cma=300 because nobody said to remove it.
4. Rebooted: it's still using swrast_dri.so (no acceleration).

On Raspbian, the X-Server never says it is loading vc4_dri.so, which it does when loading most modules, but the modesetting driver announces that the DRI and VDPAU drivers are vc4. On OpenSuSE, modesetting still thinks that "AIGLX: Screen 0 is not DRI2 capable". Both machines have libglamoregl.so installed. That's where it stands now. I'll keep trying to tweak parameters like a script kiddie, but if anyone reads this and recognizes a problem, another pointer would be very helpful. Or a reference to the "real" documentation.

[Gavinmc42]

You could use Gentoo64 instead, OpenGL works fine on that without tweaking.
I had trouble with Suse on Pi's, nearly none with Gentoo64.

[jimcuclamath]

@Gavinmc42, thanks for the suggestion and the news that Gentoo64 has OpenGL working.

Here's a report on some more progress (or non-progress).

Per ldd, all dependencies of vc4_dri.so are found; it could have been loaded.

I tried duplicating GPU-relevant parameters in Debian's kernel command line and config.txt. I completely commented out gpu_mem=32 (and removed gpu_mem= (no value)). On the command line I removed cma=300M. On Raspbian, /proc/cmdline includes vc_mem.mem_base and mem_size; I did not try to copy these. Display is hosed. Message from v3d: "Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory."

I assigned both cma=256M (on command line) and gpu_mem=256 (in config.txt).
Xorg.0.log now says: loaded modesetting. AIGLX: Screen 0 is not DRI2 capable.
Same if gpu_mem=256 is removed.

Suppose the DTB overlays contain the magic. About 40 of 170 files differ. I transplanted the Raspbian files with extension .dtb or .dtbo to SuSE. It behaved neither better nor worse than before: AIGLX: Screen 0 is not DRI2 capable. (Reverted.)

What about start.elf, which another forum post suggested contains the GPU firmware. I transplanted it from Raspbian to SuSE. It went through the SuSE pre-boot procedure ending with showing the Grub menu, implying that many parts of Raspbian's start.elf were functioning. Grub loaded the expected kernel (4.18.8-1) and initrd but exited saying ""Failed to boot both default and fallback entries". Yes the UUID in /mnt/EFI/BOOT/grub.cfg was verified correct; an error here will cause the same symptom. (Reverted to SuSE start.elf, which boots OK.) So this possibility was not successfully tested.

Could the magic be in the vc4.ko kernel module? Oops, that can't be tested because Raspbian is for 32bit armv7 while OpenSuSE is for 64bit aarch64. But thanks to @Gavinmc42: I can steal both the kernel and start.elf out of Gentoo64 for ARM and try them out (one at a time).

The reason I'm fixated on OpenSuSE is that all my other machines run it and my sysadmin framework assumes SuSE's infrastructure and directory organization.

Wish me luck; I'm going to need it.

[Gavinmc42]

Try gpu_mem=16 , that is what Gentoo64 uses.
And when you enable OpenGL driver in Raspbian it also becomes 16MB.
Eric Anholt's driver negotiates for more if it needs it.

Yep understand about switching distributions, I got me head around Debian and then piCore , tried Suse(failed).
Lucky for me Sakaki did Gentoo64, but it is weird.
Usually it is the packing methods that confuse me.

For me trying to learn OpenGL in Aarch64, Gentoo64 had everything nearly all there and installed.
Plus it has a Browser that actually works well.

[jimcuclamath]

https://www.reddit.com/r/openSUSE/comme ... _question/
OP sdoconnell "3 months ago", 2018-07-xx. He found the solution in
https://www.suse.com/documentation/suse ... rry-pi.pdf
the SuSE documention for SLES-12 SP3 on Raspberry Pi (PDF).

I did the following procedure with no problems on two different Raspberry Pi 3B's:

1. Since Eric Anholt's accelerated vc4 driver is "experimental", SuSE ships it with 3D acceleration suppressed. Edit /etc/X11/xorg.conf.d/20-kms.conf and comment out Option "AccelMethod" "none".

2. Install package Mesa-dri-vc4 which provides the direct rendering module for the X-Server.

3. In /boot/efi/extraconfig.txt you need dtoverlay=vc4-kms-v3d or dtoverlay=vc4-fkms-v3d ("fake" KMS). Other forum posts suggest that the latter one works better for streaming video, so I'm using that one.

4. The kernel command line needs a nonzero cma allocation. Based on another forum post I'm using cma=300M (unit of megabytes is required). Different people recommend different values. I suspect without proof that this is an upper bound; the driver is known to expand and contract video RAM dynamically. While other distros use /boot/cmdline, SuSE uses Grub (yay) which obeys /boot/grub2/grub.cfg which is overwritten on each update with material from /etc/default/grub. For this driver gpu_mem is irrelevant and can be left at the default (32 on SuSE, 16 on Gentoo, in megabytes).

5. Reboot, to get the changed dtoverlay=vc4-fkms-v3d and/or cma=300M.

I installed glmark2 from the SuSE repo and it got an overall score of 74, which looks like the average frames per sec of the 33 sub-tests. Comparing the overall score on different graphics platforms:
* 17 fps for a RPi 3B with software rendering.
* 74 fps for a RPi 3B with the GPU enabled, 4.4x faster.
* 1831 fps for an Intel Core i5-5200U @2.2GHz with Intel HD Graphics 5500.
* And a real gaming GPU would be faster than that.

So you won't be playing modern video games, but this is very promising for my goal of video playback. The next step is to purchase the codec licenses and install Kodi. Thank you to all who helped out on this issue and special credit to sdoconnell.

(Is there any way to edit the thread title to include "Solved"?)

[Imperf3kt]

(Is there any way to edit the thread title to include "Solved"?)

If you edit the opening post, you are presented the option to rename the thread, you can add it via this.