INTL 3:770/1 3:770/3
REPLYADDR bp@www.zefox.net
REPLYTO 3:770/3.0 UUCP
MSGID: c4d7a659
REPLY: <66678cd1@news.ausics.net> 6b02ded7
PID: SoupGate-Win32 v1.05
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)
SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 128/260 129/305
SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360
SEEN-BY: 226/17 30 100 227/114 229/110 111 112 113 200 206 300 317
SEEN-BY: 229/400 426 428 470 550 616 664 700 240/1120 266/512 267/800
SEEN-BY: 282/1038 291/111 292/854 301/1 113 812 310/31 320/219 322/757
SEEN-BY: 335/364 341/66 342/200 396/45 460/58 633/280 712/848 770/1
SEEN-BY: 770/3 100 330 340 772/210 220 230 5020/400 1042 5058/104
SEEN-BY: 5075/35
PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426
|
