Subj : Re: Pi4 to Pi5 migration To : bp@www.zefox.net From : Computer Nerd Kev Date : Tue Jun 11 2024 09:31:30 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". > 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. -- __ __ #_ < |\| |< _# --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .