INTL 3:770/1 3:770/3
REPLYADDR not@telling.you.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: <66678cd1@news.ausics.net> 6b02ded7
REPLY: e461070d
PID: SoupGate-Win32 v1.05
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)
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
|
