Bootable 64-bit RPi3 Gentoo image (OpenRC/Xfce/VC4) UPDATED

[Sakaki]

[salfter]

[Sakaki]

Hmm, that's strange. What do you get if you run:

[Sakaki]

For those who prefer a NOOBS-style installer, the v1.4.1 gentoo-on-rpi3-64bit images are now also available for install through PINN (called gentoo64 (=regular) and gentoo64pt (=pi-top) there).

Best, sakaki

PS: Many thanks to procount for helping me set up my own PINN repository (https://isshoni.org/pinn/os), and kindly linking it into the official set!
_________________
Regards,

sakaki

[salfter]

[Sakaki]

If that's the only dep you have, it should update OK. Try pulling the repo again:

[salfter]

[Sakaki]

Looks like something you have in /etc/package.mask/... locally is blocking sys-boot/rpi3-64bit-firmware-1.20190215: there's no rpi3-overlay mask affecting that package other than this one:

[salfter]

/etc/portage/package.mask/ has the following:

[Sakaki]

So if you remove the files (or move them to another holding directory somewhere):
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin
/etc/portage/package.mask/rpi3-64bit-firmware
/etc/portage/package.mask/rpi3-64bit-meta

can you then update @world?
_________________
Regards,

sakaki

[salfter]

[Sakaki]

OK I understand I think.

The problem is that you need to remove the file:
/etc/portage/package.mask/rpi3-64bit-meta

and (if you wish) also:
/etc/portage/package.mask/rpi3-64bit-firmware

Just leave the file:
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin

That should be sufficient.
_________________
Regards,

sakaki

[roylongbottom]

64 Bit High Performance Linpack Benchmark

Has anyone produced a precompiled version of the HPL benchmark to run on a Raspberry Pi 3, or detailed procedures to load the appropriate packages to compile and install one?

Some time ago, the original precompiled HPL benchmark was shown to produce the wrong numeric results or system crashes on the Pi 3B. I have recently been running two versions of the 32 bit HPL benchmarks on Raspberry Pi 3B and 3B+, via Raspbian Jessie and Stretch. The versions were an old precompiled one and another that I generated that uses ATLAS, with alternative Basic Linear Algebra Subprograms. The latter took 14 hours to build from scratch, including hundreds of MFLOPS speed tuning calculations. Although a later compiler was used, performance was slower than the original.

The benchmarks were run using a range of data sizes and options to utilise 1, 2 or 4 cores. Most tests encountered errors, using the old Pi 3B, but only during the 4 core tests, and not necessarily at high temperatures. No failures were encountered during the Pi 3B+ tests but there was an initial performance hit, using Raspbian Stretch, where the default temperature for reducing CPU clock speed, from 1400 to 1200 MHz, had been reduced from 70°C to 60°C. Note that both systems were in FLIRC cases, with efficient cooling via the built in heatsinks.

I than ran my floating point stress tests, four copies at the same time, homing in one that produced similar failures as HPL, with each using 160 KB data size, to overfill the shared L2 cache.

See 32 bit summary results in:

https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=44080&p=1448724#p1448724

and full details at ResearchGate in:

https://www.researchgate.net/publication/331983549_Raspberry_Pi_3B_and_3B_High_Performance_Linpack_and_Error_Tests

64 Bit Stress Tests


I also ran my 64 bit stress tests via Gentoo. Following is a summary of a series of tests on the older Pi 3B, where failures occurred on the third run, with performance and temperatures increasing (due to improved L2 cache hits?). The running time varied using the different logical core, when, on the final passes, two or three cores were in use, and produced higher total MFLOPS. The fourth run crashed. On rebooting there were no errors, but temperatures might not have reached the breaking point.

[Sakaki]

roylongbottom,

very interesting results, as always. In the raspberrypi.org posting you linked, you state (wrt a 32-bit system):

[brikko]

Hello everyone.

I just tried the latest image and unfortunately I'm everything but impressed with the hw video decoding.

The same file plays perfectly in LibreElEC and is completely unwatchable here, both with VLC and ffplay -vcodec h264_v4lm2m.
Lots and lots of dropped frames... 1 core is almost 100% while the others stay at about 10%.

Is this the kind of performance that we should expect from the opensource v4l2 mesa framework?

[Sakaki]

brikko,

quite possibly there will be issues with it, as it has just been introduced with kernel 4.19; presumably it will get better over time. On my tests the hardware codec paths performed significantly better on high-bitrate files than the software paths did. But they may not yet exploit all the zero-copy buffering etc. that the MMAL paths can.

The version of VLC on the image does not yet use the v4l2 m2m HW codec paths, nor does kodi etc.

ffplay should do so however, when you force the vcodec as stated.

Can you share the URL of the target file you are trying to play?
_________________
Regards,

sakaki

[brikko]

I noticed. There's definitely a difference between kodi/vlc (sw) and ffplay (hw), but even with v4l2m2m it's just not as smooth as it is with the proprietary driver, even with the basic 10Mb jellyfish test file. I can clearly see stuttering there.

The other file I tried to play is a common 1080p.AMZN.WEB-DL.DD+5.1.H.264-AJP69 mkv release.

[Sakaki]

brikko,

The other issue is pushing the rendered frames out for display. Currently, even with the v4l2 m2m codecs, this is done using a regular gl pipeline. As such, if you have a very high-res display, it can easily become the bottleneck (again, MMAL based systems can write directly, which is much faster).

Turning window-manager compositing off, and selecting the kms, rather than fkms, driver, helps with this, a bit.
_________________
Regards,

sakaki

[roylongbottom]

[Irre]

Sakaki!
Please add "samba" as default use parameter for kodi. It works, but there are too many recompilations. (My media server runs samba).

[Sakaki]

Irre,

samba USE flag added to the defaults, and rebuilt kodi-18.0 pushed to the binhost.
_________________
Regards,

sakaki

[Irre]

Thank you very much!

[Precision]

[Sakaki]

Hi Precision,

if you look at the notes accompanying the corresponding bcmrpi3-kernel-bis release (the instance of the weekly kernel autobuild which the bcmrpi3-kernel-bis-bin-4.19.25.20190226.ebuild you cited uses as its upstream), it says:

[Precision]

Thank you for the thorough explanation. We are so lucky to have you. I am sorry, however, as I still don't understand why this produces zero results: