Re: Pi4 to Pi5 migration

bp@www.zefox.net wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

 
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.
 

 
Firefox is Extended Support Release 115.11.0esr(64-bit), installed using
apt. There's a checkbox to "use hardware acceleration when available"
but no hint whether it _is_ available or in use.

The hints are all on the about:support page that I pointed you to.
To be specific, type "about:support#graphics" in the URL bar and press
Enter. There you'll find the specifics of what hardware accelleration
is used, or maybe a clue why it's not. You might need to look up the
terms used to see how they relate to the specific GPU accelleration
you want, but if my guess about your intentions is correct then look
at "HARDWARE_VIDEO_DECODING".

My browser of choice is chromium Version 124.0.6367.73 (Official Build)
Built on Debian , running on Debian 11 (64-bit). It seems a bit faster.
It also offers a checkbox "Use graphics acceleration when available"
without giving a hint of what it's actually using. I do remember that
highligting the button caused trouble around a year ago.
 
Both are up-to-date according to apt.

Debian package the ESR versions, but you could manually install the
Mozilla ARM64 Firefox binaries, though I think currently they're
only nightly builds, so the other extreme of stability. Firefox ESR
128 will be released on the 9th of July (Debian packages may take
some time longer to arrive).

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?

 
AIUI a GPU is a coprocessor with its own registers and cache that
can do single-instruction-multiple-data operations in parallel
with the CPU such as vector math. That's what I _think_ I'm looking
for. Compiler enhancements seem necessary, is that the bottleneck?

No the code running on the GPU is all written by Broadcom and Linux
software just talks to that, so nothing needs to be compiled for
the GPU in order to use functionality that's in the stock GPU
firmware. The bottleneck at this point seems to be mainly
application developers adding support for the APIs, but this isn't
an issue with compilers, just the usual limits of time, money, and
willpower.

If you want to do more with the GPU than using the routines
Broadcom's firmware includes, such as support en/decoding other
video codecs, or using it as a co-processor for non-graphics-related
tasks, then free compiler options become limited. That gets
complicated, but it's not much to do with PC-like GPU acceleration
in web browsers, that is already facilitated by Broadcom's
pre-compiled GPU firmware binary which runs on the GPU from
start-up (in fact it's what starts the CPU and Linux up).

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).

 
Do other GPU companies (Nvidia comes to mind) handle things any better?

No, it's unlikely to be in their interest to release documents to
help others write open-source firmware for GPUs, because then
people could add features and performance improvements to cheaper
GPU chips that might reduce the market for their more expensive
models. Still the degree of openness varies, overall Broadcom isn't
great, but better than Nvidia and no worse than others.

Much the same applies to other parts on the RPi boards like the
WiFi/Bluetooth chips which also run closed-source firmware
binaries. There are other SBCs that try to use more "open
hardware", but the RPis prioritise low-cost ahead of that.

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