home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 20,059 of 21,939   
   Theo to bp@www.zefox.net   
   Re: Pi4 to Pi5 migration   
   09 Jun 24 22:02:12   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR theom+news@chiark.greenend.org.uk   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  0b7343f2   
   REPLY:  e461070d   
   PID: SoupGate-Win32 v1.05   
   bp@www.zefox.net wrote:   
   > Computer Nerd Kev  wrote:   
   > > 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?   
      
   On the Pi the GPU is a black box, or rather a collection of black boxes   
   inside a black box.  There is some ability to launch code on small parts of   
   the GPU (the QPUs) and some limited compiler support for them.  But the   
   parts that are used for most of the graphics pipeline aren't accessible -   
   the GPU firmware presents an API and the Linux driver talks to that API, but   
   we don't get to look at or change the software behind the API.   
      
   > > 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?   
      
   Everyone does it.  Nvidia is much worse because, unlike RPi and AMD, they   
   don't even open source any of the software running on the CPU side of things   
   - both the kernel driver and the userspace components are closed source   
   binary-only.  Intel is probably the best in that there's good Linux drivers   
   and some documentation for how their GPU hardware works, which you don't get   
   with anyone else.   
      
   (Intel make discrete GPUs.  You can plug them in but they don't work on a Pi:   
   https://pipci.jeffgeerling.com/cards_gpu/intel-arc-a750.html   
   )   
      
   Theo   
      
   --- 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   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca