Subj : Re: Pi4 to Pi5 migration To : Computer Nerd Kev From : bp@www.zefox.net Date : Sun Jun 09 2024 14:38:29 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. 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. > 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? > > 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. > Aye, there's the rub 8-) >> 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). Do other GPU companies (Nvidia comes to mind) handle things any better? Thanks for writing! bob prohaska --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .