Dedoimedo has released an excellent tutorial on How to enable video acceleration on the Pi4 with Ubuntu MATE.
https://www.dedoimedo.com/computers/rpi4-ubuntu-mate-hw-video-acceleration.html
1 Like
Hi Frank,
Have you successfully enable OpenGL via the method described in the blog post?
Followed the post modified usercfg.txt the X is still on llvmpipe which is software rendering:
ubuntu@ubuntu:/usr/share/X11/xorg.conf.d$ glxinfo | grep OpenGL
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 10.0.1, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.2.0-devel (git-6cba468 2020-07-01 focal-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 20.2.0-devel (git-6cba468 2020-07-01 focal-oibaf-ppa)
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.2.0-devel (git-6cba468 2020-07-01 focal-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
This is my usercfg.txt:
dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-kms-v3d-pi4
max_framebuffers=2
gpu_mem=128
hdmi_enable_4kp60=1
dtparam=spi=off
disable_overscan=1
I did. On a install using Wimpy's Desktopify script.
Did you follow the author's tests commands to see if 3D drives are loaded?
I was able to use OpenGL in both Firefox and VLC.
Yes, both already been okay
antony@rp4umff:~cat /proc/device-tree/soc/firmwarekms@7e600000/status
okayantony@rp4umff:~$ cat /proc/device-tree/v3dbus/v3d@7ec04000/status
okayantony@rp4umff:~
The dmesg output also shows the driver was loaded:
[ 186.592458] rpivid-mem feb00000.hevc-decoder: rpivid-hevcmem initialised: Registers at 0xfeb00000 length 0x00010000
[ 186.592826] rpivid-mem feb10000.rpivid-local-intc: rpivid-intcmem initialised: Registers at 0xfeb10000 length 0x00001000
[ 186.593130] rpivid-mem feb20000.h264-decoder: rpivid-h264mem initialised: Registers at 0xfeb20000 length 0x00010000
[ 186.593309] rpivid-mem feb30000.vp9-decoder: rpivid-vp9mem initialised: Registers at 0xfeb30000 length 0x00010000
[ 186.605997] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 186.606509] vc_sm_cma: module verification failed: signature and/or required key missing - tainting kernel
[ 186.607519] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 186.607529] [vc_sm_connected_init]: start
[ 186.619158] [vc_sm_connected_init]: installed successfully
[ 186.635797] mc: Linux media interface: v0.10
[ 186.670139] videodev: Linux video capture interface: v2.00
[ 186.756356] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 186.759297] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 186.771643] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 186.772391] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[ 186.787119] bcm2835-isp bcm2835-isp: bcm2835_isp_probe: ril.isp returned 1 i/p (1 expected), 2 o/p (3 expected) ports
[ 186.798027] bcm2835-isp bcm2835-isp: Unregister from media controller
[ 186.798036] (efault): Unregistering node (null)[0] device node /dev/video0
[ 186.798040] (efault): Unregistering node (null)[0] device node /dev/video0
[ 186.798043] (efault): Unregistering node (null)[0] device node /dev/video0
[ 186.798047] (efault): Unregistering node (null)[0] device node /dev/video0
...
[ 187.339454] vc4-drm gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
[ 187.339467] checking generic (3e3cf000 7f8000) vs hw (0 ffffffffffffffff)
[ 187.339471] fb0: switching to vc4drmfb from simple
[ 187.340065] Console: switching to colour dummy device 80x25
[ 187.340265] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 187.340269] [drm] No driver support for vblank timestamp query.
[ 187.340273] [drm] Setting vblank_disable_immediate to false because get_vblank_timestamp == NULL
[ 187.340758] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[ 187.561374] Console: switching to colour frame buffer device 240x67
[ 187.586096] vc4-drm gpu: fb0: vc4drmfb frame buffer device
I think it's the X11 part doesn't contains driver to use the HW GL engine.
If you have time please check the glxinfo | grep OpenGL on your Rpi4 Ubuntu Mate setup, see if you get different renderer up and running.
I cannot find userconfig.txt in boot/firmware on 20.10. Please assist..
I'm with Anthony - although it's possible that hwaccel worked at the time that franksmcb tried it, it absolutely does NOT work with any of:
- MATE 20.04 64-bit, clean install. (20.04.1, to be precise. kernel 5.4)
- MATE 20.10 64-bit, clean install. (kernel 5.8)
- MATE 20.04 32-bit, clean SERVER install + desktopify.
- MATE 20.10 32-bit, #3 dist-update'd to 20.10.
I've also gone as far as pulling in the "userland" source and building and install that to provide mmal support, and then rebuilding ffmpeg from source to utilise the mmal layer. All of those variations also failed to provide any sort of hwaccel at all. All of them showed that the V3D driver was correctly in use, and all of them also show that hwaccel "should" work according to the article.
XVideo support is missing, and DRM (in the "direct rendering" sense, not "digital restriction") support is missing.
Assuming dedoimedo's article is valid, which seems likely given franksmcb's succes following it, it looks like something significant has broken since the 20.04 release.
I've also tried both the FakeKMS driver and the "real" KMS driver (via usercfg.txt) both with the same result, i.e. total failure.
Between #2 and #3, I tried a Raspbian install. That DID work, flawlessly (with VLC) out of the box, only producing about 20% cpu load, for 1080p x265. That was using a 5.10 kernel, and one that I assume also potentially had patches that hadn't been mainlined yet - certainly not for 20.04, since the Pi devs were still working on them in August of last year, and possibly still not even in the 5.8 kernel of the 20.10 release.
mmal is a legacy solution, and one that will never be available on 64-bit. That's what prompted the change to a 32-bit kernel for #3. AFAICT though, mmal doesn't actually work on the Pi4 at all with the Ubuntu kernels even after building and installing it: it seems to be missing some small last piece. (Possibly just configuration tweaks even rather than software, but whatever it is, I couldn't figure out how to fix it).
The "long-term" solution to hwaccel is v4l2, which was missing from the 20.04 release but SHOULD have been completed in time for it to work with the 5.8 kernel in 20.10. It might have just missed it though, and given that hwaccel still doesn't work, it seems that it did - except that the article and franksmcb both claim to have had working hwaccel ON 20.04, which means something in the Ubuntu ?kernels? is (a) broken AF, and (b) a regression since then.
My HOPE is that the 21.04 release will have a kernel and video stack with all the right pieces available, and everything will just work the way it's supposed to. But I wouldn't put money on it. It's possible that this is a red herring and there's some other piece that's actually causing the breakage, which could be as simple as something in a config file etc, but whatever the problem IS, if we can't track it down then the end result is the same: users end up with no hwaccel, and that sucks HARD, since even the significant CPU upgrade in the Pi4 is still a long way from being able to play even 1080 x264 reliably, let alone the much more intensive x265 and other "modern" formats. 
Right now, my plan is to try 21.04 and see what happens. If that fails as well, which is very much what I'm expecting, the only thing left to try is building the Raspbian kernel and installing that instead, which is even more work than I've already spent trying to chase this down, and a major headache long-term. But we'll see how it goes.
If anyone DOES have working hwaccel (which nobody in Wimpy's #raspberrypi channel on Discord responded "yes" to when asked the other day), it would be interesting (and very helpful!) for them to say so and provide some details to compare against.
Sidenote: Given the steps in the article, it's not really about "enabling hwaccel DECODE" directly at all - it's enabling "direct" GL ouput, which is a VERY different thing. It's possible that doing so on a system that has the underlying pieces working is enough for VLC's "Automatic" hwdecode setting to find the v4l layer and/or decide that that's the best way to go: certainly, the cost of copying frames around and/or having to reformat them is significantly higher on the Pi than it would be on a typical desktop, and that alone might be enough to cause dropped frames on a video. Given the MASSIVE cpu load drop on Raspbian, from 100% on all 4 cores to 20%, on a large HEVC video, it clearly IS also doing hw decode there as a result of the change - and we don't really care about the specifics, just that it "works".
But, on Ubuntu, it clearly just doesn't, regardless of what the VLC specifics are. And that's a real shame, because it turns the Pi4 from "a viable desktop / leisure / HTPC machine" to something that is still a viable desktop machine for "business-y" stuff, but otherwise useless other than as a server.
I'd love to see more confirmation on this topic, from people who've either somehow managed to get it to work OR people who haven't.
@franksmcb - have you by any chance actually tested clean 20.10 or 21.04 installs and had video work? Or is your success limited to only that 20.04.0 release?
You're not the only one. I'm completely up-to-date with Ubuntu MATE on the RPi4, and the performance has been fat garbage all around the board.
OpenGL doesn't seem to be working in a lot of programs (only exception has been RetroArch so far, I think? As of 21.04, most stuff just crashes with GLXBadFBConfig or whatever the ■■■■), and HW accel for video just doesn't work across the board, thus VLC seems to run like dog-ass no matter what codec I try. Apparently this thing is supposed to at least be able to do 1080p60 with h264, but it does less than a single frame per second, with plenty of corruption.
cat /proc/device-tree/soc/firmwarekms@7e600000/status returns disabled, and nothing I've tried has made it change to enabled.
What gives? I am having nothing but trouble with the RPi4 in general, and I'm wondering if this thing is a lost cause. I've tried getting the bleeding edge Mesa builds from a PPA, messing with the config.txt, spent at least 200+ hours trying to fix this thing. I'm tired, and extremely frustrated.