Re: Pi4 to Pi5 migration

bp@www.zefox.net wrote:

Scott Alfter <scott@alfter.diespammersdie.us> wrote:

In article <v3t15g$1kl11$1@dont-email.me>,  <bp@www.zefox.net> 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).

--
__          __
#_ < |\| |< _#