Subj : Re: Pi4 to Pi5 migration To : Computer Nerd Kev From : bp@www.zefox.net Date : Tue Jun 11 2024 02:13:57 Computer Nerd Kev wrote: > bp@www.zefox.net wrote: >> Computer Nerd Kev 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". > Ahh, that trick was most productive. Looks like hardware video decoding is runtime unavailable Force disabled by gfxInfo Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED Since RasPiOS' version of firefox is 115, I guess that's expected. >> 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. > Ok, that clarifies things considerably. Is the API public, at least? Then folks could experiment. > 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). > Is this to say that if somebody wanted to write a cryptocurrency miner for the Raspberry Pi VideoCore they'd need Broadcom's help? >>> 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. Thanks for writing, I've learned a lot! bob prohaska --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .