Poor WebGL performance on RPi5 #172
Comments
|
For any others that come here, I ended up forking the repo to my internal docker build, and just having it kick a build. All I changed was moving the base image to %plat%-debian-node:20-bookworm-run, since the node 16 images haven't been updated as recently as the node 20 ones. From there, it just apt-get installs chromium/mesa, so the rebuild gets latest version of those packages. Boom -- my simple mapping app went from 2-3fps up to 20fps, and the browser is way snappier to use. So, I think just doing a re-release of the package (ideally, updating to node 20) and calling it 2.7.1 would be a big benefit to the community, if anyone's still watching this... (balena feels kinda dead right now, so not sure if anyone is) |
|
| So, I think just doing a re-release of the package (ideally, updating to node 20) and calling it 2.7.1 So, 2.7.1. was released but was this added? I'm still not seeing GPU performance on a pi5 |
|
Why is that needed? |
|
I'm suggesting that they do a re-release, since simply building a new release of the image will solve the problem. I forked the dockerfile to my own buildchain and simply did a rebuild/"release" and am using that image. I honestly don't remember why I added the dbus thing. I don't see it in the example code for the browser module... |
|
Ah. That solved your performance issue on the pi5. Gonna try that also! Thx! |
|
@deregtd balena is not dead (far from it) but the main maintainer of this block (me) became annoyingly busy running the company. Although I would love to still do technical work, and have great intentions, I almost always get pulled into other matters. I will, however, endeavour to get the stack updated as you suggest. My request, in return, is if you could help me test it? We need the result to be performant on Pi3, 4, 5, zero 2 W and Intel NUC. Phil |
|
How dare you run the company! :D I only have pi 5s here, but I can try switching to a release you kick out. If you just rebuild the release, you should end up with an effectively identical image to what I have in my docker image builder repo, so I have faith, but happy to test it out when it's ready. Just lemme know. BTW, this block really needs an onscreen keyboard to be terribly useful for kiosks, btw. I def can't use this in any wider release of my stuff without an OSK. I just use a laptop/phone to change settings in the app right now, but that doesn't scale. |
|
For sure, but I have to be honest that I don't have the time to implement (and test) that. I use the browser-control block from my phone or another machine - but then I don't have to change my screens often. Mostly they just display home assistant dashboards around the house. 😁 |
|
I can test on pi4 |
|
@basz @deregtd as good as my word, I did endeavour! I bumped up the version of node and deployed the block to my own organisation (i.e. not balenalabs) and then pushed that to my application that all my screens around the house use, and.....everything is broken when I enable the GPU. :(
One thing I noticed is that the block now has a different build for RPi's and everything else, so that it can bring in the patched chromium for Pi video drivers: browser/build/install_chromium Line 21 in bff360f This takes the device type the block was built for, and if that is a RaspberryPi variant uses the "chromium-browser" instead of pure Chromium. The only block built for a RaspberryPi device type was the armv7 one:  So @deregtd the reason that you originally saw poor performance on your Pi5 may have been because you used the aarch64 block, which will have used vanilla Chromium. Now I need to figure out what is not being installed as part of the "chromium-browser" package to enable the GPU without all current weirdness. Disabling the GPU makes everything (non-webGL) work fine, FWIW. |
|
@deregtd could you push your fork to your own GH repo, so that I could take a look, please? |
|
I'm pretty sure it has no changes at all from your repo. I think I just re ran your build. Here is the docker file from my repo: |
|
Sweet! Lemme know if you have an image you want me to test on a 5. |
|
Nice! What's the correct overlay then? |
|
Cuase vc4-kms-v3d-pi5 apparently is a thing too. |
|
@deregtd I'm investigating.... |
If you use the base vc4-kms-v3d overlay, it properly uses the right version based on arch. So you can force it by adding -pi5 to the end but you don't have to. |
|
nice Phil! one snag. Error: (HTTP code 404) unexpected - pull access denied for bh.cr/gh_phil_d_wilson/browser-armv7hf, repository does not exist or may require 'docker login': denied: requested access to the resource is denied |
|
@basz sorry, try now. I forgot to make it public and was using it from inside my own org. |
|
np & thx. building and deploying now. ready for when i get to my work studio. will report. |
|
pi4 and pi5 confirmed to work! awesome. |
|
All fixed in version 2.8.0 |
|
@deregtd not dead, just spinning many plates 😉 |
|
thank you very much! |
|
Unfortunately, on an RPi 5, bumping from my fork ("2.7.1") up to the latest 2.9.0 causes the very slow performance to return. :( Using image: Output on console on startup: Using my older working build: The key thing I was trying to eliminate earlier was the: I've attached my entire image build folder for my local balena-browser build that gave me a working build with no v3d errors, at least as of 2 months ago, in case it helps: |
|
@deregtd could you try the arm7hf version of the block, please? |
|
I tried the arm7hf version and it immediately quits with error 139. I'm running a 64-bit os on rpi 5, using the balena base image untouched. So I'm guessing it doesn't support mismatched architecture images out of the box? |
|
nice job! that is the reason for my bad performance, playing videos on a pi5 vs an x64 pc. looking forward for a release! |
|
Sorry @deregtd - I missed the replies (and got busy on company "stuff" again). I'll try to look at this again this weekend. Also pinging @rahul-thakoor and @mtoman to similarly make them feel guilty about letting down the faithful browser block community. 😄 |
|
We've packaged our boat up for the winter, so I don't have a way to test this until the spring, btw. :( |
I'm using the browser module out of the box (v2.7.0) on my 8GB Raspberry Pi 5, with ENABLE_GPU=1 and other such niceties, on a 1080p touchscreen on HDMI, all deployed via balena:
My application is a webgl-based application that does map rendering, and poor performance (1fps even though the render function takes ~15ms to run) is pointing to something very wrong with the hardware pipeline on the balena block. I then tried doing the basic WebGL Aquarium sample and the browser gets 7-8fps on there with 500 fish (default mode). Even when I disable all the maps so my application is rendering a blank screen with an arrow in the center, it's still only getting 7-8fps (with a render function well below 1ms now).
I've checked chrome://gpu and all the usual stuff is enabled. Other benchmarks on a Pi5 suggest that I should be getting 30-40fps.
Any idea what's up here? It's looking like I'm going to have to bail on having a pi5 power my kiosk and just get a cheap android tablet to hit the website served by the pi remotely.
The text was updated successfully, but these errors were encountered: