9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] Question re: RPI video performance
@ 2022-12-02 14:49 Nicola Girardi
  2022-12-02 16:21 ` Sigrid Solveig Haflínudóttir
  2022-12-04 18:53 ` Kristo
  0 siblings, 2 replies; 11+ messages in thread
From: Nicola Girardi @ 2022-12-02 14:49 UTC (permalink / raw)
  To: 9front

Hi all,

I have been using 9front on a RPI2b+ for more than a month now
and it's great except that drawing is really slow; I'm not complaining
of course, I'm just curious about the reason, since I remember the
display working more smoothly with another OS.

To give an idea of the lag I'm experiencing, if I type in acme's tag,
the window below it is redrawn after every character, and the time it
takes is such that I see all the redraws and I have to wait for the
display to catch up with what I typed.  I tried to time this and I'm
able to type 3 chars a second.

Also if the display's too busy updating, mouse movement is very slow.

Thanks for any knowledge y'all may want to share.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-02 14:49 [9front] Question re: RPI video performance Nicola Girardi
@ 2022-12-02 16:21 ` Sigrid Solveig Haflínudóttir
  2022-12-03  9:48   ` Nicola Girardi
  2022-12-04 18:53 ` Kristo
  1 sibling, 1 reply; 11+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2022-12-02 16:21 UTC (permalink / raw)
  To: 9front, Nicola Girardi

Could be related to the framebuffer format. Check "aux/zerotrunc </dev/screen". Try to switch to a different format via config.txt(?), especially if your current mode is 16-bit.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-02 16:21 ` Sigrid Solveig Haflínudóttir
@ 2022-12-03  9:48   ` Nicola Girardi
  2022-12-03 10:02     ` Steve Simon
  0 siblings, 1 reply; 11+ messages in thread
From: Nicola Girardi @ 2022-12-03  9:48 UTC (permalink / raw)
  To: 9front

Sigrid Solveig Haflínudóttir <sigrid@ftrv.se> wrote:
> Could be related to the framebuffer format. Check "aux/zerotrunc </dev/screen". Try to switch to a different format via config.txt(?), especially if your current mode is 16-bit.

Interesting.  I had only configured the mode using hdmi_mode=82 in
config.txt and got r5g6b5 as output to your command.  I now realize I
can additionally set vgasize in cmdline.txt to 1920x1080x32, then I
get

; read -c 60 /dev/screen
   x8r8g8b8           0           0        1920        1080 

Slow as before.  Tried many other modes in the past month, and even
640x350 behaves in the same way I'd described earlier.

One thing I noticed in the config.txt provided by 9front is that
gpu_mem is set to 16, while the default is 64.  As a total hunch I
tried to increase that value to 64 but then the RPI doesn't boot (or
boots, but screen is blank so I don't know :-)).

I can accept the behavior, it's just I'd like to understand more.  I
tried to understand something from the git history but failed.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03  9:48   ` Nicola Girardi
@ 2022-12-03 10:02     ` Steve Simon
  2022-12-03 11:12       ` Nicola Girardi
  0 siblings, 1 reply; 11+ messages in thread
From: Steve Simon @ 2022-12-03 10:02 UTC (permalink / raw)
  To: 9front

you are sure it is video performance that is slow and not something else?

try cat /sys/lib/words (rusty memory, probably the wrong path).

you could also try the trusty catclock.

i have never used 9front on the pi but miller’s distro was fine, and the video driver is probably the same…

-Steve


> On 3 Dec 2022, at 09:50, Nicola Girardi <ng@0x80.stream> wrote:
> 
> Sigrid Solveig Haflínudóttir <sigrid@ftrv.se> wrote:
>> Could be related to the framebuffer format. Check "aux/zerotrunc </dev/screen". Try to switch to a different format via config.txt(?), especially if your current mode is 16-bit.
> 
> Interesting.  I had only configured the mode using hdmi_mode=82 in
> config.txt and got r5g6b5 as output to your command.  I now realize I
> can additionally set vgasize in cmdline.txt to 1920x1080x32, then I
> get
> 
> ; read -c 60 /dev/screen
>   x8r8g8b8           0           0        1920        1080 
> 
> Slow as before.  Tried many other modes in the past month, and even
> 640x350 behaves in the same way I'd described earlier.
> 
> One thing I noticed in the config.txt provided by 9front is that
> gpu_mem is set to 16, while the default is 64.  As a total hunch I
> tried to increase that value to 64 but then the RPI doesn't boot (or
> boots, but screen is blank so I don't know :-)).
> 
> I can accept the behavior, it's just I'd like to understand more.  I
> tried to understand something from the git history but failed.
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03 10:02     ` Steve Simon
@ 2022-12-03 11:12       ` Nicola Girardi
  2022-12-03 11:53         ` Steve Simon
  0 siblings, 1 reply; 11+ messages in thread
From: Nicola Girardi @ 2022-12-03 11:12 UTC (permalink / raw)
  To: 9front

Steve Simon <steve@quintile.net> wrote:
> you are sure it is video performance that is slow and not something else?

In fact, I'm not sure at all.

OTOH, I'm aware that screen updates can become very slow when the
system is under load, but that's understandable.  If I load a page in
mothra, say, the mouse becomes much less responsive until the page is
fully loaded.  But the slow screen updates also happen when the system
is idle (I mostly only do text editing).

> try cat /sys/lib/words (rusty memory, probably the wrong path).
> 
> you could also try the trusty catclock.

I'm not sure I understand your test; you're proposing to run programs
that don't do much other than updating the screen; if they run fast,
the video performance is good enough and the slowness I'm observing is
due to something else.  Is that right?

Catclock runs smoothly, but admittedly only updates a small part of
the screen.  Cat'ing a large file (in a window with scroll enabled) is
indeed slow.  Unhiding a rio window is slow to redraw, even if it's
just a window running rc where I previosly cat'ed a file.

> i have never used 9front on the pi but miller’s distro was fine, and the video driver is probably the same…

I'd try that for comparison but I'm not sure I have a spare sd card,
I'll check.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03 11:12       ` Nicola Girardi
@ 2022-12-03 11:53         ` Steve Simon
  2022-12-03 16:13           ` Nicola Girardi
  2022-12-03 16:13           ` Eckard Brauer
  0 siblings, 2 replies; 11+ messages in thread
From: Steve Simon @ 2022-12-03 11:53 UTC (permalink / raw)
  To: 9front


which pi do you have, the ancient ones can be slow but 3b and 4 have been fine for me.

it is true that plan9 doesnt make very much use of the gpu, but it  use it. comparing to x11 or wayland, plan9 is probably never going to be as fast.

> On 3 Dec 2022, at 11:14, Nicola Girardi <ng@0x80.stream> wrote:
> 
> Steve Simon <steve@quintile.net> wrote:
>> you are sure it is video performance that is slow and not something else?
> 
> In fact, I'm not sure at all.
> 
> OTOH, I'm aware that screen updates can become very slow when the
> system is under load, but that's understandable.  If I load a page in
> mothra, say, the mouse becomes much less responsive until the page is
> fully loaded.  But the slow screen updates also happen when the system
> is idle (I mostly only do text editing).
> 
>> try cat /sys/lib/words (rusty memory, probably the wrong path).
>> 
>> you could also try the trusty catclock.
> 
> I'm not sure I understand your test; you're proposing to run programs
> that don't do much other than updating the screen; if they run fast,
> the video performance is good enough and the slowness I'm observing is
> due to something else.  Is that right?
> 
> Catclock runs smoothly, but admittedly only updates a small part of
> the screen.  Cat'ing a large file (in a window with scroll enabled) is
> indeed slow.  Unhiding a rio window is slow to redraw, even if it's
> just a window running rc where I previosly cat'ed a file.
> 
>> i have never used 9front on the pi but miller’s distro was fine, and the video driver is probably the same…
> 
> I'd try that for comparison but I'm not sure I have a spare sd card,
> I'll check.
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03 11:53         ` Steve Simon
@ 2022-12-03 16:13           ` Nicola Girardi
  2022-12-05 17:00             ` Nicola Girardi
  2022-12-03 16:13           ` Eckard Brauer
  1 sibling, 1 reply; 11+ messages in thread
From: Nicola Girardi @ 2022-12-03 16:13 UTC (permalink / raw)
  To: 9front

Quoth Steve Simon <steve@quintile.net>:
> 
> which pi do you have, the ancient ones can be slow but 3b and 4 have been fine for me.

This one's a 2b+, but I had the same behavior with a 3b+.

I did try Miller's image (with some effort, as I didn't have a spare
SD card, but was curious) for comparison and the video *seems* faster
but I think it's just because the acme implementation there doesn't
redraw a window each time a character is added to its tag.  :-)


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03 11:53         ` Steve Simon
  2022-12-03 16:13           ` Nicola Girardi
@ 2022-12-03 16:13           ` Eckard Brauer
  1 sibling, 0 replies; 11+ messages in thread
From: Eckard Brauer @ 2022-12-03 16:13 UTC (permalink / raw)
  To: 9front

Just tried it on RPi 2 vs. RPi 3 (OP has Pi 2, ref. 1st message).

"cat /lib/words" needs 32 s on RPi 2 and ~ 1 s on RPi 3 for me, and
that's really caused by the output, as "cat /lib/words > /tmp/file" is
also fast (time told me about 0.1 s).

Never noticed that before.

> which pi do you have, the ancient ones can be slow but 3b and 4 have
> been fine for me.
>
> it is true that plan9 doesnt make very much use of the gpu, but it
> use it. comparing to x11 or wayland, plan9 is probably never going to
> be as fast.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-02 14:49 [9front] Question re: RPI video performance Nicola Girardi
  2022-12-02 16:21 ` Sigrid Solveig Haflínudóttir
@ 2022-12-04 18:53 ` Kristo
  2022-12-04 20:11   ` Nicola Girardi
  1 sibling, 1 reply; 11+ messages in thread
From: Kristo @ 2022-12-04 18:53 UTC (permalink / raw)
  To: 9front

Hi,

I happen to own the Pi 2 Model B V1.1 and I definitely can't reproduce
this "3 chars a second" performance with the latest 9front image. For
example, the speed of scrolling output in a rio terminal is completely
reasonable.

0.00u 0.01s 0.66r 	 cat /lib/words

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-04 18:53 ` Kristo
@ 2022-12-04 20:11   ` Nicola Girardi
  0 siblings, 0 replies; 11+ messages in thread
From: Nicola Girardi @ 2022-12-04 20:11 UTC (permalink / raw)
  To: 9front

Quoth Kristo <kristo.ilmari@gmail.com>:
> Hi,
> 
> I happen to own the Pi 2 Model B V1.1 and I definitely can't reproduce
> this "3 chars a second" performance with the latest 9front image. For
> example, the speed of scrolling output in a rio terminal is completely
> reasonable.
> 
> 0.00u 0.01s 0.66r 	 cat /lib/words

TL;DR I have similar results for this test.

The "3 chars a second" refers to typing in acme window tags.  The "cat
/lib/words" test yields different timings based on the window height;
for a very short window it's very fast, for a fullscreen window it's
very slow.

; grep cat./ /dev/text
0.00u 0.01s 0.59r 	 cat /lib/words
0.00u 0.02s 3.04r 	 cat /lib/words
0.00u 0.00s 5.15r 	 cat /lib/words

Also, using a smaller font yields gives better results (the above is
with a large font, more suitable to my eyes).

; echo $font
/lib/font/bit/vga/vga.font
; grep cat./ /dev/text
0.00u 0.01s 0.62r 	 cat /lib/words
0.00u 0.00s 1.02r 	 cat /lib/words
0.00u 0.00s 1.61r 	 cat /lib/words

Using the vga font, typing on acme window tags is faster than 3 chars
a second, but still seeing the window below flicker all the while.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9front] Question re: RPI video performance
  2022-12-03 16:13           ` Nicola Girardi
@ 2022-12-05 17:00             ` Nicola Girardi
  0 siblings, 0 replies; 11+ messages in thread
From: Nicola Girardi @ 2022-12-05 17:00 UTC (permalink / raw)
  To: 9front

Quoth Nicola Girardi <ng@0x80.stream>:
> Quoth Steve Simon <steve@quintile.net>:
> > 
> > which pi do you have, the ancient ones can be slow but 3b and 4 have been fine for me.
> 
> This one's a 2b+, but I had the same behavior with a 3b+.
> 
> I did try Miller's image (with some effort, as I didn't have a spare
> SD card, but was curious) for comparison and the video *seems* faster
> but I think it's just because the acme implementation there doesn't
> redraw a window each time a character is added to its tag.  :-)

The above experiment led me to the conclusion that I could run 4e acme
in 9front to have fewer redraws, at the expense of not having 9front's
new features and bugfixes.  Incredible how easy it was to do that
thanks to namespaces and static binaries: I bound the plan9-4e sources
to /sys/src, a ramfs to /arm/lib, and built acme and necessary
libraries from there, installed in /arm/bin, then deleted the window.

Thanks for the hints given so far.

Nicola


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-12-05 17:02 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-02 14:49 [9front] Question re: RPI video performance Nicola Girardi
2022-12-02 16:21 ` Sigrid Solveig Haflínudóttir
2022-12-03  9:48   ` Nicola Girardi
2022-12-03 10:02     ` Steve Simon
2022-12-03 11:12       ` Nicola Girardi
2022-12-03 11:53         ` Steve Simon
2022-12-03 16:13           ` Nicola Girardi
2022-12-05 17:00             ` Nicola Girardi
2022-12-03 16:13           ` Eckard Brauer
2022-12-04 18:53 ` Kristo
2022-12-04 20:11   ` Nicola Girardi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).