New Mesa drivers

I had also tried that too. dtoverlay=vc4-kms-v3d-pi4 will not work with my VIZIO tv except if fbturbo is enabled but I lose V3D. My tv has always had an issue with getting providing edid info.

Bottom line is the image we provide with it’s defaults, glxgears or glxinfo will not work here on my setup with any current mesa* packages in any of our repo branches. My tv could be the issue and the new mesa’s has regressed in regards configuring it’s self for my tv.

I did run vulkaninfo using the mesa-git in the unstable branch and it gave the same output you posted above so guessing it is getting info built in mesa-git.

Is your hdmi cable 2.0? Usually “high speed” is printed on the cable. Some recent change “broke” my video with a non 2.0 (1.4?) cable. If you boot with 2.0 and then swap the cables, video works. So while a non-compliant cable can function, it will not correctly ID a monitor. If your cable is not 2.0, it might be worth trying a new cable.

Edit: And btw, when it was broke, I hunted through the hdmi_group and hdmi_mode settings until I eventually found settings that worked. My guess is, if your tv will work, there is a manual setting, unless you are very unfortunate. And I’ll bet with a Vizio, one of those settings will work.

The cable is an official 4K compliant cable bought from the pi store. But my tv is not high speed or 4K. The problem is it defaults to a non compliant resolution (1366x768). This has never been a problem with the other pi’s but from the first day with the pi4 it will not boot and just hangs at boot with a black screen trying to get edid info. There is a special section in the pi video documentation regarding this resolution and it does boot when you set the monitor info manually with the defaults in our images.

Where it starts having issues is with the kms-v3d-rpi4. It will boot and gives output loading the kernel but when it gets to loading up the graphics I get nothing but a black screen with the cursor. It can not find my tv info needed to finish loading.

Ugh, then you are unfortunate. I noticed that glaring NOT for RPi4 and wondered about it. And the mode 87 did not work? Surely some combination works, even if it is some SVGA mode. :smiley: Just so you can load the driver and know it is working, for testing purposes.

And btw, for folks that may have the same. The 1.4 hdmi cable was from a year old CanaKit and it worked until 5.9 or 5.10. The more recent CanaKit cables are 2.0 and work as expected.

I can confirm that the mesa-git in the unstable branch makes the vkcube spin, so it is looking good to go.

I installed a fresh plasma image using the unstable branch and all is good with glxgears. Guessing that other files needed upgraded also it depends on. The price of branch hopping.

Ah! excellent news. I am of the mind to give plasma a try too, good to know it is working.

Have you tried firefox. I swear things are better on youtube with vulkan. Set enviorment first and run firefox:

MOZ_ACCELERATED=1
MOZ_WEBRENDER=1
firefox

I switched over my windows box and I am in the middle of downloading the Plasma image, my DSL is slow. I’ll give it a try in an hour or so.

I have crappy dsl also but I was able to let it cache first and could play some of the higher speed videos that were jerky in the past.

Well, in Firefox 1080p it still has a ways to go. Stats for Nerds shows way too many dropped frames. However, at 720p it does pretty well.

But Firefox also spit out several of these errors:

[Child 2412, MediaDecoderStateMachine #1] WARNING: Decoder=ffff694c1c00 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - RefPtr<MediaSourceTrackDemuxer::SamplesPromise> mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: file /build/firefox/src/firefox-83.0/dom/media/MediaDecoderStateMachine.cpp:3471

Chromium seems to have lost support, no OpenGL and no Vulkan, both show as disabled. It had OpenGL support with Mesa 20.2.3. And at 720p it has too many dropped frames.

In general use, the v3dv driver is smooth enough and is stable. But, I don’t notice much difference in performance between v3d and v3dv.

If you were asking about performance relative to the fbturbo driver? I think the performance of general desktop use is fairly comparable even at 4K. I did not previously test youtube with fbturbo other than checking to see if it worked at all. But frankly, I was hoping the v3d driver would have resulted in a larger performance increase. I still have hope, but I hope for less.

I tested mpv using “mpv --gpu-api=vulkan” a little and do not know if it was better or not with the videos I had.

I also tested browserbench.org’s MotionMark and the score was higher but not much but I guess any little bit of increase can only help:

firefox: 7.06
firefox in the vulkan enviourment: 8.36

I have Plasma on Wayland at the moment and so far it is going fairly smoothly. I just ran the MotionMark and got 9.47 +/- 21.94%. When I tried the webgl aquarium, a very steady 11 fps which is up 1 fps.

I may have to switch from Xfce4, I like this.

Wow, I installed Plasma to my existing xfce4 arm-unstable, per the Manjaro Wiki, and performance is poor. glxinfo shows v3d as the renderer. However if I run glxgears, it struggles to stay close to 60 fps… like 57 or 58. And the drop shadow behind the glxgears window flickers. Something is different between a clean Plasma install and adding the desktop environment along side xfce4. I am still starting with lightdm rather than sddm, but I don’t think that would be the cause.

Please check your Display and Compositor settings.

3d acceleration on Plasma would be using the GPU, which (as far as I know) is not really ready on Raspberry Pi 64-bit.

Interesting, it shows OpenGL 2.0 as the compositor. But it sure feels like software rendering.

What’s the content of /etc/environment?

If it’s empty, it’s using hardware rendering, but as the driver is “incomplete” on 64-bit it’s expected to not be good.

$ cat /etc/environment

#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
QT_QPA_PLATFORMTHEME=qt5ct

But I seem to have an issue with kwin. It crashes with both xorg and wayland sessions. Below is the error with xorg.

Executable: kwin_x11 PID: 2586 Signal: Segmentation fault (11) Time: 11/27/20 5:24:16 AM CST

And if I click on Developer Information, the debugger quits unexpectedly.

Edit: I did not have this issue with a clean Plasma install and then update to unstable. This is the result of a Plasma install on a xfce4 unstable. I had Plasma on Wayland running wonderfully on mesa-git with the clean install. And my xfce4 still runs fine.

Edit 2: When I did the install, I did not choose the default gsteamer backend, so that could be a difference.

1 Like

I copied the working Plasma install partition from the SD over to my SSD. Now running Plasma on Wayland with the v3dv driver from SSD, and no kwin crashes and the compositor shows OpenGL 3.1 and vulkaninfo reports positively.

Performance is nice and snappy.