Subj : Re: Pi4 to Pi5 migration To : bp@www.zefox.net From : Computer Nerd Kev Date : Sun Jun 09 2024 10:19:12 bp@www.zefox.net wrote: > Scott Alfter wrote: >> In article , wrote: >>>One thing I hadn't considered until now is migrating away from >>>RasPiOS to something else. Are there any alternatives that offer >>>comparable support that will run on the Pi5? >> >> It depends on what you want to do. > > Probably browser performance is the main bottleneck. Far as I know > the RasPiOS version of chromium is the only browser that exploits > the VideoCore portion of the Pi. Via Mesa drivers, hardware 3D graphics rendering should be supported in Firefox just like on PC, this has been the case for years. Check the details on the about:support page to see whether Firefox on your RPi has detected that it's available. Of course it's really a matter of what you mean by "exploits". Even pure framebuffer mode uses "the VideoCore portion of the Pi", so what specific exploitation are you looking for? > Is this still true? I believe Chromium has HW video decoding on the Pi (not sure about encoding), so that's probably what you mean. A quick search for "Raspberry pi firefox hardware video decoding" brings up many results announcing that support was added in Firefox 116. Note that this means it's not available in the current Firefox ESR releases, if you're using them. > It's been a genuine dissapointment that Broadcom failed to open > VideoCore in a useful way. It's most of the Pi's horsepower. Or, > am I being unfair? If you're talking about video en/decoding, then yes that's a bit unfair because Broadcom have made the APIs for common functionality like that available. Also the Raspberry Pi developers have access to all the secret documentation and development kits from Broadcom, and it's the code that they've written for their fork of the Linux kernel which has become some of the unofficial open-source reference material for talking to the RPi's GPU. As the ones selling the product, traditionally it's their job to submit code to projects like Firefox to help get it supported if they so desire, or fork them like they've done with the Linux kernel. Actually Firefox is apparantly using a Linux kernel interface for this video decoding support, so the RPi developers have up an API as conveniently as possible and left the Firefox developers to take the last step of using it at their end (quite a few years after Chromium, VLC, FFmpeg, etc. did). So you could blame Mozilla too for being so slow. Take your pick. What Broadcom would enable by fully open-sourcing their GPU code and documentation is that the firmware that these APIs talk to could be expanded as well. Then extra GPU-accellerated functions could be written such as for newer video codecs, or other things entirely. By publishing the documentation for the QPU units in the VideoCore IV GPUs Broadcom did open some doors towards that, but it's not really enough information for a full open-source GPU firmware to be independently developed (there's a project for that with VideoCore IV, but it stalled years ago). -- __ __ #_ < |\| |< _# --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .