128x128 (128x64 ABCDE x2) is slow on rPiB and slower with --led-pixel-mapper="U-mapper"

[marcmerlin]

On an rPiB, I run ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=adafruit-hat-pwm -D 0 --led-rows=64 --led-cols=128 --led-multiplexing=0 --led-row-addr-type=0 --led-chain=2 --led-show-refresh --led-slowdown-gpio=0 --led-pixel-mapper="U-mapper" and I only get a measly 55Hz, which is not great.

If I remove --led-pixel-mapper="U-mapper", then I get 59Hz. Is U-mapper on 2 panels only supposed to be that slow?

On an rPi3, ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=adafruit-hat-pwm -D 0 --led-rows=64 --led-cols=128 --led-multiplexing=0 --led-row-addr-type=0 --led-chain=2 --led-show-refresh --led-slowdown-gpio=0
is 94Hz which is better but still on the slow side. Is 94Hz as fast as it gets for 128x128?

Adding --led-pixel-mapper="U-mapper" crashes the system instantly even if I remove -pwm and just use --led-gpio-mapping=adafruit-hat-pwm

Can U-mapper be to blame for crashes?

[marcmerlin]

Actually -D4 crashes on rPi3 without "U-mapper"

root@rPi3:~# lsmod |grep snd_bcm2835
root@rPi3:~# grep w1-gpio /proc/cmdline 
root@rPi3:~# uname -r
4.14.98-v7+
root@rPi3:~# cat /etc/debian_version 
9.8

[hzeller]

You can get much faster updates if you don't use 1:32 multiplexing (64 panels), but 1:16 or even 1:8 (the so-called 'outdoor' panels don't have this limitation). In general, the 64 high panels are pretty slow, but 55Hz is very much so.

On a Pi3 I get about 140Hz refresh for the set-up you do above, with the regular mapping, so I don't know what else you're doing on your pi (Linux 4.9, debian 9.1). So don't know where the difference between 94 and 140Hz is. Did you mess with the compile-options and changed -O3 to -O0 ? that would give you around 94Hz.

(In general I strongly suggest to use parallel chains, as they don't use more CPU but you get more pixels for less load. So in your case you'd only have --led-chain=1 and --led-parallel=2 ... and don't even need an U-mapper).

(I don't know what you mean when you refer to PiB, but I would avoid the old, single-cored Pis).

The U-mapper should not make any difference in speed as it just sets up a look-up table initially and it is is only really used when setting pixels; while dumping out the data to the panel, the U-mapper has no influence at all (Cache misses of course can make setting pixels a little slower, but it should not change your refresh rate unless you do a lot on that board, which you shouldn't).

[marcmerlin]

Thanks for the quick answer.

Funny, while you were typing this, I just setup my active-3 board I had ordered online and ran with root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-multiplexing=0 --led-row-addr-type=0 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=2 -D 0 97.5HzSize: 128x128. Hardware gpio mapping: regular Press to exit and reset LEDs 100.7Hz (delay 0 is not stable) So I get 100Hz instead of 94Hz. Faster but not much.

Your other questions: 1) point taken about 1:32. I ordered some 128x64 panels, that's how they came (and they have that new chip that needs the out of band reset script before they'll even light up) 2) I didn't change compile options or touch the makefile. I could add -funroll-loops gentoo-style :) 3) switching to 2 chains gave me an extra 5Hz, not nothing but not much

Yeah, I agree U-mapper shouldn't make things slower, it just does on the rPiB, but not on the rPi3 (well, for the single Hz setting I get before it crashes that is).

Anyway, thanks for the sanity check, at least I know I should be getting more. I'll try more things when I have time.

[hzeller]

You can increase refresh speed with --led-pwm-dither-bits which in particular might help with these slow 1:32 panels.

[marcmerlin]

thanks @hzeller with --led-pwm-dither-bits=1 I get 148.5Hz and with --led-pwm-dither-bits=2 I get 252.1Hz on a rPi3. If that looks good enough to you, let's close this bug

[angelogoncalve]

Also I think you can do this Marc:

--led-pwm-lsb-nanoseconds=250

or

--led-pwm-bits=1

[marcmerlin]

Thanks @angelogoncalve , I think you want to take nanoseconds down to increase the framerate. I took it down all the way to 50, and get no ghosting, maybe because I have the newer FM6126A chips (which need a special init as per https://github.com/hzeller/rpi-rgb-led-matrix/issues/807 but are designed to be faster). Likely they could go faster than 50ns even, although the code limits me to 50. I now have 195Hz instead of 95Hz without using dither. Thanks.

~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-multiplexing=0 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=2 -D 0 --led-pwm-dither-bits=0 --led-pwm-lsb-nanoseconds=50

[marcmerlin]

@hzeller I patched the code to allow me to take led-pwm-lsb-nanoseconds all the way down to 1, and confirmed my FM6126A panels work all the way down to 8, which gives me a refresh of 310Hz for 128x128 on 2 channels (I otherwise get 98Hz with the default of 130). I'll admit that 8 and the associated refresh rate, does look dimmer though. ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-multiplexing=0 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=2 -D 0 --led-pwm-dither-bits=0 --led-pwm-lsb-nanoseconds=8

I can get 280Hz that looks bright enough with --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=50

--led-pwm-dither-bits=2 --led-pwm-lsb-nanoseconds=10 gives me 310Hz too, I think I may be CPU limited by then.

[marcmerlin]

Mmmh, but even at 300Hz+, it looks perfect to the human eye, but not so much to the camera https://photos.app.goo.gl/Ts1CVuM5Aqns5fM77 looks like it's demo dependent, based on what the rPi3 is busy doing? -D0 is a bit better: https://photos.app.goo.gl/oaQsH8DSiux1ShPf7

[angelogoncalve]

Dear Marc, you can increase the refresh rate, I think increasing the variable in the line command doing this change:

--led-slowdown-gpio=2

[hzeller]

LED panels are very bright, so the cameras switch to a very short exposure time. If you have a regular camera, close the aperture as much as possible. If you have a cell-phone, film through a dark filter, e.g. sunglasses.

[marcmerlin]

@angelogoncalve I'm already using --led-slowdown-gpio, thanks for the suggestion. @hzeller good point. Either way, seems that the numbers I'm getting with a few command line tricks, are good enough, so if you agree, feel free to close Henner. Although please note the "--led-pwm-lsb-nanoseconds=8". I'm not sure if you'd be happy allowing a number all the way down to 10 (from 50). You can of course trivially patch this, or if you'd like a PR, I can send one too.

[hzeller]

Did you measure that you get a proper 8ns pulse at the end of the line ? The chips on these boards are pretty slow, so I doubt that it even lights up the LEDs. I don't remember the details, but I think there were also lock-up situaitons with much smaller numbers in the past, but it could be with the old single-core Pis, which are unfortunately still used today with the Pi Zero.

[marcmerlin]

No, I didn't measure the pulse, I'm not equipped for that :) I did however see the Hz going up as I took the number down from 50ns to ever lower numbers, and if I take from 8 to 7, display breaks entirely (on a Pi3). As you said, it may break earlier on other Pis or other panels, but ideally the command line option would not hardcode an arbitrarily high limit (50), when some combinations can run at 10 or less, that is unless going below 50 would actually damage some hardware, in which case forcing a higher number for safety, would make sense.

[marcmerlin]

As per the other rpi0w bug, I'm starting to understand that ultimately this library does much better with faster Pis. Chasing performance issues on older Pis may not be a good use of time (except maybe rpi0 since it is so much smaller and would help designs where you could stick a pi0 directly into the hub75 plug on the panel), so I think it's fair to close this bug. https://github.com/hzeller/rpi-rgb-led-matrix/issues/972 can followup (if desired) on how to improve performance on smaller Pis.