Skip to content

Commit

Permalink
RPi: drop Slice/Slice3 devices in options file
Browse files Browse the repository at this point in the history 
Signed-off-by: Matthias Reichl <hias@horus.com>
  • Loading branch information
@HiassofT
HiassofT committed Sep 28, 2020
1 parent 4bc115d commit 8e6605f
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions projects/RPi/options
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@
arm)
# Valid TARGET_CPU for Raspberry Pi based devices are:
# arm1176jzf-s cortex-a7 cortex-a53
if [ "$DEVICE" = "RPi" -o "$DEVICE" = "Slice" ]; then
if [ "$DEVICE" = "RPi" ]; then
TARGET_CPU="arm1176jzf-s"
elif [ "$DEVICE" = "RPi2" -o "$DEVICE" = "Slice3" ]; then
elif [ "$DEVICE" = "RPi2" ]; then
TARGET_CPU="cortex-a7"
elif [ "$DEVICE" = "RPi4" ]; then
TARGET_CPU="cortex-a53"

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 17, 2021 •
edited

For RPi4, shouldn't the following be:

TARGET_CPU="cortex-a72"

AFAIK, the RPi3 uses the a53.

This comment has been minimized.

Sign in to view

Copy link
@HiassofT

HiassofT Jan 17, 2021

Author Member

See comment in PR: 8e6605f#commitcomment-46040436

cortex-a72 caused odd issues

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 24, 2021

@HiassofT - Sorry, which PR? The link seems to be circular to this commit.

This comment has been minimized.

Sign in to view

Copy link
@HiassofT

HiassofT Jan 24, 2021

Author Member

sorry - probably wrong c&p.

The RPi4 PR #3597, esp this comment #3597 (comment)

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 24, 2021 •
edited

Thanks very much for the link. I wonder if the gdb lock-up is still present now that you're on a much newer kernel version? I have been building Matrix for Arch ARM with -mtune=cortex-a72 stuff and cannot get gbm to lock up as you describe.

I actually patch ffmpeg to use it, see: https://github.com/graysky2/PKGBUILDs/blob/kodi-aarch64/alarm/kodi-rpi-git/0000-use-mcpu-avoiding-march-and-mtune.patch

Beyond that, see: https://github.com/graysky2/PKGBUILDs/blob/kodi-aarch64/alarm/kodi-rpi-git/PKGBUILD#L143-L152

This comment has been minimized.

Sign in to view

Copy link
@HiassofT

HiassofT Jan 24, 2021

Author Member

I can't remember any issues with gbm lockup. The issue with cortex-a72 optimization was that gdb was looping forever in the python thread backtrace.

Also note that we are building for 32bit arm, not aarch64.

I suspected this could be a compiler bug - 32bit arm plus cortex-a72 optimization is probably a really small niche, aarch64 is certainly a lot more widespread. Unfortunately the only obivious issue was the kodi+python+gdb combination - and that is not a testcase small enough to look for assembler code differences...

Could be that the issue is gone now with newer gcc/gdb/python but TBH it's prettly low priority for me - it needs extensive testing so I'd rather leave this to someone else who has the time and motiviation (also I'm not too convinced that optimizing for corttex-a72 will give a huge performance improvement over cortex-a53)

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 24, 2021

Sorry, typo, I meant gdb not gbm (edited). Your reply makes sense. Thanks again for all the time and info you shared.

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 25, 2021

(also I'm not too convinced that optimizing for corttex-a72 will give a huge performance improvement over cortex-a53)

I am thinking about what would be a reproducible and quantitative measure to compare generic *FLAGS to specific ones specifically for Kodi. I think the major "work" kodi does is to play back video content. I am wondering what a good measure of this is for this purpose.

%CPU usage during playback might a metric, but since ffmpeg offloads decoding of both HEVC and h264, I do not think corresponding differences in load would be reflected.

Is there a standard for Kodi others have used in the past to assess the effect of different *FLAGS or do you have any suggestions for such a metric?

This comment has been minimized.

Sign in to view

Copy link
@HiassofT

HiassofT Jan 25, 2021

Author Member

HW video decode is probably the more uninteresting part as it'll be limited by HW decoders.

SW decoded video, (python) addon performance, core kodi DB/(xml-)parsing etc might be more interesting as they are likely more CPU intensive.

On 32bit ARM https://github.com/bavison/arm-mem gave a bit of a speedup as the 32bit ARM libc string functions aren't as optimized as the aarch64 ones - they also showed up as hotspots in perf

This comment has been minimized.

Sign in to view

Copy link
@graysky2

graysky2 Jan 25, 2021

Thanks for the tips!
Expand All @@ -26,9 +26,9 @@
# This specifies what floating point hardware (or hardware emulation) is
# available on the target. Permissible names are:
# vfp neon-vfpv4 neon-fp-armv8
if [ "$DEVICE" = "RPi" -o "$DEVICE" = "Slice" ]; then
if [ "$DEVICE" = "RPi" ]; then
TARGET_FPU="vfp"
elif [ "$DEVICE" = "RPi2" -o "$DEVICE" = "Slice3" ]; then
elif [ "$DEVICE" = "RPi2" ]; then
TARGET_FPU="neon-vfpv4"
elif [ "$DEVICE" = "RPi4" ]; then
TARGET_FPU="neon-fp-armv8"
Expand Down

0 comments on commit 8e6605f

Please sign in to comment.