jc-kynesim / rpi-ffmpeg

FFmpeg work for RPI
Other
111 stars 25 forks source link

How can I get a HW decoder for hevc under X11? #9

Closed Fredrum closed 2 years ago

Fredrum commented 3 years ago

Hello! After having run the 'jc-kynesim/hello_drmprime' successfully in the CLI environment I'm encouraged to try and make hevc hardware decode under X11 (desktop) to add to a project!

But while the hello_drmprime code clearly uses the Pi4b hardware decoding when I try in CLI (no X11) I only seem to be able to get software decode in X11(desktop).

I built and installed 'test/4.3.2/rpi_main'. The following config flags were used: configuration: --disable-mmal --enable-sand --enable-v4l2-request --enable-libdrm --enable-libudev --enable-opengl --extra-cflags=-I/usr/include/libdrm

I'm on a RPi4b 32bit Buster Kernel 5.10.52-v7l+

I have these video devices from ls -la /dev/video* crw-rw----+ 1 root video 81, 5 Aug 29 00:04 /dev/video10 crw-rw----+ 1 root video 81, 6 Aug 29 00:04 /dev/video11 crw-rw----+ 1 root video 81, 7 Aug 29 00:04 /dev/video12 crw-rw----+ 1 root video 81, 1 Aug 29 00:04 /dev/video13 crw-rw----+ 1 root video 81, 2 Aug 29 00:04 /dev/video14 crw-rw----+ 1 root video 81, 3 Aug 29 00:04 /dev/video15 crw-rw----+ 1 root video 81, 4 Aug 29 00:04 /dev/video16 crw-rw----+ 1 root video 81, 0 Aug 29 00:04 /dev/video19

When I run this I get output but at the same slow (software) rate that I think I get in my test program, (run from the source built ffmpeg directory) ./ffmpeg -no_cvt_hw -vcodec hevc -i ~/Videos/jellyfish-40-mbps-hd-hevc.mkv -f opengl -

The following might be a relevant code section in my test program:

    if(softwareDecoder -> id == AV_CODEC_ID_H264) {
        decoder = avcodec_find_decoder_by_name("h264_v4l2m2m"); // Runs fast!
    }

    if(softwareDecoder -> id == AV_CODEC_ID_HEVC) {
        decoder = avcodec_find_decoder_by_name("hevc");  // Runs slow!
    }

    if(!decoder) {
        printf("decoder not found");
        return -1;
    }

    //hw_pix_fmt = AV_PIX_FMT_DRM_PRIME;   // commented out

Full and messy WIP code here: https://github.com/Fredrum/hwdectogl/blob/master/glHevc.c

Any ideas what I can do to pick up the hardware hevc decoder instead?

P.s I'm confused about the role of 'drm' in all of this. It sounds like it should be a render-to-screen thing but also seems tied to the hw decode? I would have thought the decode should be separate and independednt of the rendering?

Cheers Fred

jc-kynesim commented 3 years ago

I didn't choose "drm" as a name I inherited it from other V4L2 request code - it refers to the buffer type not decode or display.

When building ffmpeg for test make sure you build a static link one - I'm not utterly sure which is the default these days - otherwise you'll get the system libs which is confusing.

The line you want is: ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i <h265 stream> -f vout_egl /dev/null

HOWEVER this will not work; you'll get errors on every frame when it tries to display, due to the current released mesa (GL) not being able to cope with the SAND8 / SAND30 format that the decoder produces. If you update mesa to HoT it might work for SAND8 (I admit to only trying with a carefully crafted mesa from the people doing the mesa work). I think I mentioned this in the hello_drmprime thread.

To show that the egl output is good (H264 decode can produce NV12 / YUV which is coped with) ./ffmpeg -no_cvt_hw -vcodec h264_v4l2m2m -i <h264 stream> -f vout_egl /dev/null

If you want to check that the h265 decode is good - switch away from X and use ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i <h265 stream> -f vout_drm /dev/null

which should do the same as hello_drmprime (indeed uses the code I copied to build hello_drmprime).

DISCLAIMER to anyone reading this thread: The egl_vout / drm_vout devices are development test devices, and examples of how you can display drm frames. I have no current intention to convert them into anything more generally useful than they are at the moment. If someone else wishes to do that work then I will very happily take the patches, but it is currently not on my roadmap.

Fredrum commented 3 years ago

Thanks for the clarification about "drm". Some reasons it was confusing was that the variable used for it was const char * hwdev = "drm"; so I thought it was meant to set the hardware device, ie decoder unit or something. Also if I enter something else than "drm" in that variable I get the error message, Available device types: vdpau vaapi drm. and I had it in my mind that those other two were some kind of hardware decode api's or drivers.

I'll get started trying to build ffmpeg as static lib I have found some instructions for that.

When I run this under X11 and inside the custom ffmpeg folder, ./ffmpeg -no_cvt_hw -vcodec h264_v4l2m2m -i ~/Videos/jellyfish-40-mbps-hd-h264.mkv -f vout_egl /dev/null I get the error message:

Requested output format 'vout_egl' is not a suitable output format
/dev/null: Invalid argument

I got that earlier too which is why I changed 'vout_egl' to 'opengl'. But that does not work either in this particular command string.

But let me build for static first and try again!

Fredrum commented 3 years ago

Hmm have you got any typed notes for how to build your rpi fork as static? I found instructions based on the 'John Van Sickle' code and binaries but I would need to build your fork+branch.

I tried just adding the 'static' options to the config command before building yours but I don't think that worked. ie, --enable-static --disable-shared

UPDATE: I'm not sure how static the ffmpeg is meant to be? The following is the output of ldd ./ffmpeg:

    linux-vdso.so.1 (0xbeed1000)
    /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f4a000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6eb1000)
    libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6e82000)
    libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 (0xb6da1000)
    libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6d14000)
    libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0xb6bbe000)
    libsndio.so.7.0 => /usr/lib/arm-linux-gnueabihf/libsndio.so.7.0 (0xb6b9f000)
    libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6b80000)
    libXv.so.1 => /usr/lib/arm-linux-gnueabihf/libXv.so.1 (0xb6b6c000)
    libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6a4a000)
    libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6a2b000)
    libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6a00000)
    libmmal_core.so => /opt/vc/lib/libmmal_core.so (0xb69e2000)
    libmmal_util.so => /opt/vc/lib/libmmal_util.so (0xb69c2000)
    libmmal_vc_client.so => /opt/vc/lib/libmmal_vc_client.so (0xb69a7000)
    libbcm_host.so => /opt/vc/lib/libbcm_host.so (0xb6980000)
    libvcsm.so => /opt/vc/lib/libvcsm.so (0xb6966000)
    libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb6936000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb690c000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb67be000)
    /lib/ld-linux-armhf.so.3 (0xb6f5f000)
    libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb67ab000)
    libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb6796000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6783000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb676c000)
    libGLdispatch.so.0 => /usr/lib/arm-linux-gnueabihf/libGLdispatch.so.0 (0xb66ed000)
    libGLX.so.0 => /usr/lib/arm-linux-gnueabihf/libGLX.so.0 (0xb66ce000)
    libbsd.so.0 => /usr/lib/arm-linux-gnueabihf/libbsd.so.0 (0xb66a6000)
    libvcos.so => /opt/vc/lib/libvcos.so (0xb668d000)
    libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0xb6677000)

UPDATE 2: Well it seems this build is doing some stuff right as when I switch to CLI(non x11) and run: ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i <h265 stream> -f vout_drm /dev/null

I get an image at a definitely hw accelerated ~122fps and it prints out, Hwaccel V4L2 HEVC Stateless V1

Great! So I know that's working! :)

So I'm back at the original question then, how do I get the HW acceleration to kick in under X11? (I'm currently just looking at the pace of printed messages in the decode loop, I'm not trying to pass to GL yet)

UPDATE 3: Oh wait! This is now actually working, tested under X11/Desktop: ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i ~/Videos/jellyfish-40-mbps-hd-hevc.mkv -f null -

fps=133 speed=4.43x [hevc @ 0x25ccc40] Hwaccel V4L2 HEVC stateless V1; devices: /dev/media0,/dev/video19

So I need to figure out what this does that I don't! Actually running ldd on my own executable shows that it's picking avcodec libs from the standard system and not your ones. I can see that I have the new .a libs in /usr/local/lib so I try to link directly to those like this,

ifndef FFINSTALL
FFINSTALL=/usr
endif
LIBS    := -L$(FFINSTALL)/lib/arm-linux-gnueabihf -lGLESv2 -lglfw -lEGL -L/usr/local/lib/libavcodec.a -L/usr/local/lib/libavutil.a -L/usr/local/lib/libavformat.a -ldrm -lpthread -lm

But that ends up giving me a whole load of undefined references with various avcodec things.

jc-kynesim commented 3 years ago

OK if you get "'vout_egl' is not a suitable output format" then you are missing libs that it wants (it wants some slightly odd ones). Check it turns up in devices post config. I'm not sure this is a complete list of the extras that might be useful over the old standard but try: sudo apt install meson libepoxy-dev libxcb-dri3-dev libxcb1-dev libx11-dev libx11-xcb-dev libdrm-dev

For the config I use (assuming you are compiling on a Pi) then "pi-util/conf_native.sh --noshared" will create a directory under "out" called something like "armv7..." depending on what debian version you are compiling on. cd to there and make.

Beware that if poking in pi-util that some of the scripts and notes have rotted since I wrote then and some will only work in my setup - you have been warned.

Fredrum commented 3 years ago

Hi Yes I am building on a RPi4b. I followed your above notes and it seems to have gone well. Except that something seem broken. I get the gl window thrown up but then something is not working and I never get an image in the window. The output I get is:

Input #0, matroska,webm, from '/home/pi/Videos/jellyfish-40-mbps-hd-h264.mkv':
  Metadata:
    encoder         : libebml v1.2.0 + libmatroska v1.1.0
    creation_time   : 2016-02-06T04:00:54.000000Z
  Duration: 00:00:30.03, start: 0.000000, bitrate: 39833 kb/s
    Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
[h264_v4l2m2m @ 0x363f210] level=41
[h264_v4l2m2m @ 0x363f210] Using device /dev/video10
[h264_v4l2m2m @ 0x363f210] driver 'bcm2835-codec' on card 'bcm2835-codec-decode' in mplane mode
[h264_v4l2m2m @ 0x363f210] requesting formats: output=H264 capture=YU12
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_v4l2m2m) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[h264_v4l2m2m @ 0x363f210] Post G selection ret=0, err=22 1920x1088
[h264_v4l2m2m @ 0x363f210] Dq event 5
libEGL warning: DRI2: failed to authenticate
[vout_egl @ 0x365ea60] EGL version 1.4
Output #0, vout_egl, to '/dev/null':
  Metadata:
    encoder         : Lavf58.45.100
    Stream #0:0(eng): Video: wrapped_avframe, drm_prime, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
    Metadata:
      encoder         : Lavc58.91.100 wrapped_avframe
[vout_egl @ 0x365ea60] Failed to import fd 5
[vout_egl @ 0x365ea60] Failed to import fd 6
[vout_egl @ 0x365ea60] Failed to import fd 7
[vout_egl @ 0x365ea60] Failed to import fd 800:00.36 bitrate=N/A speed=0.728x    
[vout_egl @ 0x365ea60] Failed to import fd 9
[vout_egl @ 0x365ea60] Failed to import fd 10
[vout_egl @ 0x365ea60] Failed to import fd 11
[vout_egl @ 0x365ea60] Failed to import fd 12
etc
jc-kynesim commented 3 years ago

OK - dunno. That error is saying that EGL doesn't want to import the dmabufs that decode has produced. I just installed a clean 32-bit buster distribution and built ffmpeg as I told you to build ffmpeg and it worked for me. I have gpu_mem=256 in /boot/config.txt which the default doesn't but I'd hope that wasn't the issue (nonetheless try it just in case).

I don't get the "libEGL warning: DRI2: failed to authenticate" warning so I'm going to guess that it is relevant. Are you using the default pi user or one of your own? if the latter does your user belong to all the groups that pi does (in particular video)?

Fredrum commented 3 years ago

Oh sorry I keep forgetting that I'm actually on a Retropie image, which is Raspian but with modifications. After work I'll make a fresh SD card with the latest Raspberry OS and will try with and without the gpu memory increase.

Fredrum commented 3 years ago

OK so I re-flashed an sd card with

Raspberry Pi OS with desktop
Release date: May 7th 2021
Kernel version: 5.10

Prepared with the following:

sudo apt update
sudo apt full-upgrade

sudo apt install cmake  (sudo apt install build-essential)
sudo apt install meson libepoxy-dev libxcb-dri3-dev libxcb1-dev libx11-dev libx11-xcb-dev libdrm-dev
sudo apt install libudev-dev
sudo apt install libglfw3-dev libgles2-mesa-dev
sudo apt install libsdl2-dev

Set the GPU memory split to 256. Added the overlay for the hw v4l2 decode devices. Rebooted

Cloned the repo: git clone --branch test/4.3.2/rpi_main https://github.com/jc-kynesim/rpi-ffmpeg.git
Ran the config+build as you described.

The h264 command then worked and showed the video in the GL window. (although it made the mouse movements really stuttery even as CPU was at 20%)

But the h265 command did the same things as before with the failing fd. Here's the new output:

pi@raspberrypi:~/dev/rpi-ffmpeg/out/armv7-buster-static-rel $ ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i ~/Videos/jellyfish-40-mbps-hd-hevc.mkv -f vout_egl /dev/null
ffmpeg version n4.3-dev-4125-g4044f5f5a5-rpi Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 8 (Raspbian 8.3.0-6+rpi1)
  configuration: --prefix=/home/pi/dev/rpi-ffmpeg/out/armv7-buster-static-rel/install --libdir=/home/pi/dev/rpi-ffmpeg/out/armv7-buster-static-rel/install/lib/arm-linux-gnueabihf --incdir=/home/pi/dev/rpi-ffmpeg/out/armv7-buster-static-rel/install/include/arm-linux-gnueabihf --arch=armv6t2 --cpu=cortex-a7 --disable-stripping --disable-thumb --enable-v4l2-request --enable-libdrm --enable-epoxy --enable-libudev --enable-vout-drm --enable-vout-egl --disable-shared --enable-mmal --enable-rpi --extra-cflags='-ggdb -D__VCCOREVER__=0x4000000 -mfpu=neon-vfpv4 -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux' --extra-cxxflags='-D__VCCOREVER__=0x4000000 -mfpu=neon-vfpv4 -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux' --extra-ldflags=-L/opt/vc/lib --extra-libs='-Wl,--start-group -lbcm_host -lmmal -lmmal_util -lmmal_core -lvcos -lvcsm -lvchostif -lvchiq_arm -Wl,--end-group' --extra-version=rpi
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
Input #0, matroska,webm, from '/home/pi/Videos/jellyfish-40-mbps-hd-hevc.mkv':
  Metadata:
    COMPATIBLE_BRANDS: iso4hvc1iso6
    MAJOR_BRAND     : iso4
    MINOR_VERSION   : 1
    ENCODER         : Lavf56.3.100
  Duration: 00:00:30.10, start: 0.067000, bitrate: 40015 kb/s
    Stream #0:0(und): Video: hevc (Main), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 29.97 tbc (default)
    Metadata:
      CREATION_TIME   : 2016-02-05 02:06:48
      LANGUAGE        : und
      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite
Stream mapping:
  Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[hevc @ 0x1e33780] Hwaccel V4L2 HEVC stateless V1; devices: /dev/media1,/dev/video19
qent_base_realloc: Overrun 372247 > 200704; trying 393216
qent_base_realloc: Overrun 289284 > 200704; trying 393216
qent_base_realloc: Overrun 231803 > 200704; trying 262144
qent_base_realloc: Overrun 256273 > 200704; trying 262144
[vout_egl @ 0x1e3ccc0] EGL version 1.4
Output #0, vout_egl, to '/dev/null':
  Metadata:
    COMPATIBLE_BRANDS: iso4hvc1iso6
    MAJOR_BRAND     : iso4
    MINOR_VERSION   : 1
    encoder         : Lavf58.45.100
    Stream #0:0(und): Video: wrapped_avframe, drm_prime, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
    Metadata:
      CREATION_TIME   : 2016-02-05 02:06:48
      LANGUAGE        : und
      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite
      encoder         : Lavc58.91.100 wrapped_avframe
[vout_egl @ 0x1e3ccc0] Failed to import fd 20
[vout_egl @ 0x1e3ccc0] Failed to import fd 230:00.06 bitrate=N/A speed= 0.1x    
[vout_egl @ 0x1e3ccc0] Failed to import fd 22
[vout_egl @ 0x1e3ccc0] Failed to import fd 24
qent_base_realloc: Overrun 243233 > 200704; trying 262144
[vout_egl @ 0x1e3ccc0] Failed to import fd 21
[vout_egl @ 0x1e3ccc0] Failed to import fd 31
[vout_egl @ 0x1e3ccc0] Failed to import fd 28
etc
jc-kynesim commented 3 years ago

I quote from earlier:

The line you want is: ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i -f vout_egl /dev/null

HOWEVER this will not work; you'll get errors on every frame when it tries to display, due to the current released mesa (GL) not being able to cope with the SAND8 / SAND30 format that the decoder produces. If you update mesa to HoT it might work for SAND8 (I admit to only trying with a carefully crafted mesa from the people doing the mesa work). I think I mentioned this in the hello_drmprime thread.

Fredrum commented 3 years ago

Ah right! Yes ok so we have arrived at that! I have a few questions about that, what is meant by 'HoT'? Is it the latest running version (from git)? And I need to build it myself? Iv'e got the impression that its a very big build, are there are any pre-built versions that would work? And SAND8/30 I am assuming those are pixel formats?

jc-kynesim commented 3 years ago

HoT = "Head of Tree" i.e. master. Yes you'll need to build it yourself, its not a huge build, but it needs the right config options that I've now forgotten. I'm not aware of any adequately recent pre-built packages but that doesn't mean they aren't out there. SAND8/30 are indeed pixel formats - may be called something like NV12_COL128 elsewhere.

Fredrum commented 3 years ago

Ok great! Thank you so much for all the help so far! :) I'll go and try to get mesa built and I'll report back here if I do and what the results were! Thank You!

Fredrum commented 3 years ago

Wooo! It's working!! :D I found some mesa build hints on the Raspberry forums and the build worked fine first time. The problem was that the system wouldn't see the new Mesa install just the old standard version that ships with the distro.

I'll update here tomorrow with the the full list of steps for anyone else who wants some hints on building Mesa.

Now running the command, ./ffmpeg -no_cvt_hw -hwaccel drm -vcodec hevc -i ~/Videos/jellyfish-40-mbps-hd-hevc.mkv -f vout_egl /dev/null Shows me the unpaced 4xspeed version and I don't get that sluggish mouse behaviour. It's still using 20% cpu but that might be the non optimized vout_egl then?

This is great! Thank you so much jc-kynesim for all the help! I'm going to try and see if I can add this to the project i'm working with.

Cheers!

graysky2 commented 3 years ago

@Fredrum - Quite a bit in this issue. Do you have a short write up detailing the steps you took to build? Maybe I need to read through this on not using a phone and after I have some coffee.

Fredrum commented 3 years ago

The steps for building this ffmpeg version is found above in this thread. I will put them again on one of my git projects but probably not for a while.

My notes on building latest (as of writing) Mesa are:

sudo pip3 install mako sudo apt install bison byacc flex sudo apt install libxcb-glx0-dev libxcb-shm0-dev libxcb-dri2-0-dev libxcb-present-dev sudo apt install libxshmfence-dev

git clone https://github.com/mesa3d/mesa.git cd mesa

meson --prefix /usr --libdir lib -Dplatforms=x11 -Dvulkan-drivers=broadcom -Ddri-drivers= -Dgallium-drivers=v3d,kmsro,vc4 -Dbuildtype=release build

sudo ninja -C build -j3 sudo ninja -C build install

sudo apt install mesa-utils (for glxinfo) glxinfo -B

The main hurdle was to figure out why the install doesn't trump the distro included old mesa. Also I'm wondering why that seems to be installed in two locations on Rasberry OS, /lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf

The one you build will get installed in the location pointed to by '--prefix /usr' seen above.

Then what I did was, sudo nano /etc/ld.so.conf.d/000-AAA-Mesa.conf and just add /usr/lib Basically pointing to where you install the new mesa.

sudo ldconfig Reboot

Then if you run glxinfo -B you should get something like,

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Broadcom (0x14e4)
    Device: V3D 4.2 (0xffffffff)
    Version: 21.3.0
    Accelerated: yes
    Video memory: 3660MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 4.2
OpenGL version string: 2.1 Mesa 21.3.0-devel (git-c679dbe09c)
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.0-devel (git-c679dbe09c)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10