06-09-2023, 11:17 AM
(06-08-2023, 10:30 PM)Fishwaldo Wrote: if you want a practical proof of the GPU "working" do this:
Load my desktop image (or kernel on armbian etc) and execute in a terminal window
"cat /sys/kernel/debug/pvr/status" and then do move some windows or play a video:
"Every 2.0s: cat /sys/kernel/debug/pvr/status star64: Fri Jun 9 04:49:23 2023
Driver Status: OK
Device ID: 0:128
Firmware Status: OK
Server Errors: 0
HWR Event Count: 0
CRR Event Count: 0
SLR Event Count: 0
WGP Error Count: 0
TRP Error Count: 0
FWF Event Count: 0
APM Event Count: 243
GPU Utilisation: 93%
"
Now do the same with your Framebuffer app, and not that the GPU utilization does not go above 0%.
I've written both framebuffer apps and X apps, so these details are already familiar.
However when I was running X and seeing it run slow and with artifacts, I was using xterm, xconsole, and the Motif window manager, none of which use any part of Mesa,
and X claimed in its log to be using the "fb" device, so it shouldn't have been trying to use an 3D objects and textures to place windows. In fact, it didn't so any such thing because if you watch what happens when I moved a window, it didn't slide like a 3D object would.
Here is the evidence again in case you missed it:
https://youtu.be/Le2g9Kx-pjI
And of course, the fbdev test program that I ran, if it wasn't using any part of the GPU, should not have displayed any out-of-order drawing, but it did.
Therefore it seems it is the GPU driver which is providing /dev/fb0 functionality but that driver is buggy.