•   
  • 1
  • 313
  • 314
  • 315(current)
  • 316
  • 317
  • 495
  •   
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
Why even bother with clock throttling on RPi? The power savings are negligible (if any) but the "sliding" Estuary GUI is way more smooth when using "force_turbo=1"
(2018-03-09, 18:43)smp1 Wrote: Why even bother with clock throttling on RPi? The power savings are negligible (if any) but the "sliding" Estuary GUI is way more smooth when using "force_turbo=1"
It reduces temperature which can lead to throttling, so can help performance.
(2018-03-09, 18:05)popcornmix Wrote: @J_E_F_F and this is which playing hevc? Is it keeping up okay?

There is a change in behaviour over previous firmware.
Previously we just had the concept of "turbo mode" or "idle mode".
When the arm was busy (one core > 50% busy) we would enter turbo mode.
When the gpu was busy (e.g. with HEVC acceleration) we would enter turbo mode.

Turbo mode would boost the arm and gpu clocks to maximum (subject to temperature throttling).

Since the rewrite things are more fine grained. We can have just the gpu boosted if that is all that is required.
So, my guess is the HEVC file isn't loading the arm heavily, but is using the GPU.

So we boost the GPU clocks but leave the arm at the lower frequency (as it doesn't need the higher one).
The side effect is the reporting of the arm cpu percentage is relative to the arm clock rate.

Previously you were seeing ~40% CPU from a 1200MHz arm clock.
Now you are seeing ~80% CPU from a 600MHz arm clock.

The new behaviour is actually better from a power/temperature point of view, so if we are keeping up fine then there isn't a problem.
If we are dropping frames, then we could make the HEVC decode also boost the arm frequency.

Playing a harder file may trigger the arm to run at 1200MHz which will show a lower cpu percentage.
Also running with force_turbo=1 will show a lower cpu percentage (as you'll be fixed at 1200MHz).
ok, I am seeing this, thanks for the explanation. I reinstalled 0305 and see it pegged at 1200/400 not overclocked and 1200/500 overclocked.
with 0307, it stays at 600/400 most of the time with intermittent bursts to 1200/400 (not overclocked because it crashes)

Temps with 0305 and 0307 not overclocked are the same. With 0305 overclocked the temp is about 3 degrees higher.

There is still an issue with this new firmware and overclocking (at least on my rp3) and of course the crash on stop still remains that is being worked on elsewhere.
Looks like we have progressed to where overclocking isn't needed for hevc content which is nice, but would still be nice if it worked. I don't want to use force turbo.
(2018-03-08, 06:53)doug Wrote:
(2018-03-07, 10:34)lrusak Wrote: I need to get you guys to tell me what key isn't mapped. You have to do this via command line in an ssh session.

I only use long press with Enter. Here's the results. I noticed I needed an extra "-" in libinput-list-devices and libinput-debug-events
Code:
Kodi-theatre:~ # libinput-list-devices
Device:           flirc.tv flirc
Kernel:           /dev/input/event0
Group:            1
Seat:             seat0, default
Capabilities:     keyboard
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

For the next step, I didn't see any results even though I was pressing buttons. Odd.
Code:
Kodi-theatre:~ # libinput-debug-events --device /dev/input/event0
-event0 DEVICE_ADDED flirc.tv flirc seat0 default group1 cap:k

Tried evtest and got this:
Code:
This device is grabbed by another process.
No events are available to evtest while the
other grab is active.
In most cases, this is caused by an X driver,
try VT-switching and re-run evtest again.
Run the following command to see processes with
an open fd on this device
"fuser -v /dev/input/event0"
 @doug try stoping kodi first [code]systemctl stop kodi[/code[
"PPC is too slow, your CPU has no balls to handle HD content." ~ Davilla
"Maybe it's a toaster. Who knows, but it has nothing to do with us." ~ Ned Scott
(2018-03-09, 19:36)J_E_F_F Wrote: Looks like we have progressed to where overclocking isn't needed for hevc content which is nice, but would still be nice if it worked. I don't want to use force turbo. 

So it crashes with overclock and doesn't crash without overclock.
Can you work out the minimum addition that makes it crash?
I suggest starting from everything commented out and adding in this order:

sdram_schmoo=0x02000020
over_voltage_sdram=5
over_voltage=2
sdram_freq=580
core_freq=500
gpu_freq=500
dtparam=sd_overclock=83

Report which is the first line added that makes it unreliable.
did that yesterday, these 2 lines, each individually cause a crash
core_freq=500
gpu_freq=500
(2018-03-09, 20:27)J_E_F_F Wrote: did that yesterday, these 2 lines, each individually cause a crash
core_freq=500
gpu_freq=500
 Those lines would be expected to crash without the over_voltage setting.

Are you saying:
over_voltage=2
core_freq=500

as the only setting cause a crash?
that's true, I can't say for sure if I used over_voltage yesterday when tested individually. I'll try it again and ensure over_voltage
OK, with both

over_voltage=2
core_freq=500
gpu_freq=500

it crashes in a couple seconds, and while ssh accepted a reboot command, it was hung so I needed to pull the plug for a reset.
------------------
with:
over_voltage=2
gpu_freq=500

It played for a minute or so, and as soon as I skipped forward, it crashed. This also accepted a reboot command but was hung and required the plug to be pulled before it would reboot.
-------------------
with :
over_voltage=2
core_freq=500

I didn't experience a crash
(2018-03-09, 17:00)MidKnight Wrote: Using a logitech elite remote, the long press on the enter key used to bring up the context menu, but at some point past,

LibreELEC-RPi2.arm-9.0-Milhouse-20180218010737-#0217-gc2fd843

till the lastest release i just tried, it no longer working, but insteads just fires enter cmd untill button released.

how can i change this back?

thanks

Most likely the libinput change in #0302 - see if #0301 works. This is still something we're trying to work out a fix for.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-03-09, 18:01)polo_joe Wrote: Latest build 0308 again works for me.

This is the IP address issue?

Are you on WiFi or wired, is this a RPi2 or RPi3? The only kernel related change in #0308 is a fix for an issue with Generic device tree introduced in #0307, maybe in #0307 the Generic DT issue caused a problem with some drivers? Otherwise not really sure what the problem was with #0307 and networking - my wired RPi3 picked up an IP address without any issue.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-03-09, 20:52)J_E_F_F Wrote: OK, with both

over_voltage=2
gpu_freq=500

It played for a minute or so, and as soon as I skipped forward, it crashed. This also accepted a reboot command but was hung and required the plug to be pulled before it would reboot.
So, gpu_freq=500 is equivalent to:
core_freq=500
isp_freq=500
h264_freq=500
isp_freq=500

Now, it sounds like core_freq=500 is okay. h264_freq won't be used either in gui of hevc decode.
isp_freq is used for 10-bit hevc (but not 8-bit) - is the file 10-bit? If it is then trying:
over_voltage=2
isp_freq=500

would be interesting.

Otherwise try:
over_voltage=2
v3d_freq=500
and

over_voltage=2
core_freq=500

finally froze after probably 20 minutes, with audio issues, frozen screen and sounds like someone repeatedly hitting a hammer. required a power pull too
if this link works, here is a short video of how it froze, make sure your sound is on
https://www.youtube.com/watch?v=uWbky_S1KBk
@J_E_F_F  Does it only crash with HEVC? Is HEVC 10-bit?
  •   
  • 1
  • 313
  • 314
  • 315(current)
  • 316
  • 317
  • 495
  •   



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)24
This forum uses Lukasz Tkacz MyBB addons.