pica200
Posts: 181
Joined: Tue Aug 06, 2019 10:27 am

Re: DVFS Firmware

Sun Nov 24, 2019 10:52 pm

You must have been lucky for yours to boot at all. Maybe core_freq=500 fixes the freezes for you?

goodburner
Posts: 60
Joined: Sun Jun 16, 2019 3:20 am

Re: DVFS Firmware

Mon Nov 25, 2019 9:48 am

I'm running with this now and it appears to be fine, haven't run any tests yet though. I guess the gpu_freq part is redundant in the config, but adding core_freq=500 makes it boot with gpu_freq config uncommented, whereas it was not booting without core_freq, as mentioned in that github comment linked a few posts back.

arm_freq=1925
over_voltage=3
gpu_freq=600
core_freq=500

Linux raspynew 4.19.85-v7l+ #1279 SMP Fri Nov 22 15:51:49 GMT 2019 armv7l GNU/Linux

pica200
Posts: 181
Joined: Tue Aug 06, 2019 10:27 am

Re: DVFS Firmware

Mon Nov 25, 2019 11:07 am

That's good to hear. Maybe someone knowledgeable wants to explain why it suddenly works increasing core_freq.

florca
Posts: 33
Joined: Fri Jun 29, 2012 7:54 pm
Location: South Devon, UK

Re: DVFS Firmware

Wed Nov 27, 2019 12:47 pm

Working very nicely with a lightly-loaded, non-overclocked Pi4B OMV-5(beta) Server - Idle temps dropped by at least 5°C :D

Thanks!

laurent
Posts: 331
Joined: Thu Jul 26, 2012 11:24 am

Re: DVFS Firmware

Wed Nov 27, 2019 1:52 pm

Nice update, also working well for me on my Pi41G idling on my desk at work.
With the Pi enclosed on the official case, I won 4°C.

guiloma
Posts: 2
Joined: Tue Jun 12, 2012 1:25 pm

Re: DVFS Firmware

Wed Nov 27, 2019 9:39 pm

For me, the new firmware is working correctly in general but since I updated, I note that the USB device I use (ConBee II, for home automation) disconnects after some time (several hours). dmesg shows:

Code: Select all

[63522.365147] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[63522.381191] xhci_hcd 0000:01:00.0: Host halt failed, -110
[63522.381198] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[63522.381262] xhci_hcd 0000:01:00.0: HC died; cleaning up
[63522.381332] usb 1-1: USB disconnect, device number 2
[63522.381343] usb 1-1.4: USB disconnect, device number 4
[63522.381690] cdc_acm 1-1.4:1.0: failed to set dtr/rts
When this happens, the only way to get the USB back is to restart the Raspberry.

To be honest, it is not clear to me if this problem arose because of the DVFS firmware or any other update (the ConBee firmware may have been also updated?). I am trying to locate more precisely the issue, but without success so far.

Other than this, the update is quite positive in terms of temperature. 8-)

Chimneyfactory
Posts: 44
Joined: Sun May 19, 2019 1:30 pm

Re: DVFS Firmware

Fri Nov 29, 2019 12:06 am

This might be 100% expected behavior of this test firmware, but it caught me out - and if it isn't expected/known, can I bring it to your attention : new firmware doesn't seem to change voltage / frequency behavior if 64 bit kernel is enabled.

Pi 4 4gb initial boot from SD then Raspbian on USB3 SSD. General purpose machine, working well.

sudo rpi-update

Firmware upgrades as expected. Shutdown, power off, restart.

bcmstat shows constant Vcore of 0.838, ARM freq fluctuating only between 1500 & 600.

????

Much fiddling, re-applying firmware, rolling back (with no success) then later remember that I was also trying out the 64 bit kernel.

comment out

#arm_64bit=1

Restart and now Vcore happily moving between 0.8100 and 0.8438 (are these expected voltage variations?) and ARM freq of 600, 750, 1000 and 1500Mhz.

So, the new firmware seems to have no effect for me if the 64 bit kernel is enabled, but works as expected if 64 bit isn't enabled.

Thanks,

Ian

ebin-dev
Posts: 4
Joined: Fri Nov 22, 2019 1:03 pm

Re: DVFS Firmware

Fri Nov 29, 2019 2:16 pm

The current beta firmware has a huge effect on idle power consumption: it saves about 300mW in idle mode but only if the 32bit kernel is used (power consumption 2.7W in idle mode with wifi and bluetooth disabled, access via ssh - no monitor attached).

Idle CPU temperature is around 42°C and during a stress test (compiling squid from sources with 5 instances in parallel fully loads all 4 cores) the maximum temperature reached during the 25 minute compilation was 57°C. No thermal throttling.
However, I use a huge passive heat sink for the Pi 4B (4GB) (https://www.reichelt.de/housing-for-ras ... GE=EN&&r=1)

The 64 bit kernel would not appear to benefit from the recent DVFS patches. cpufreq-info (apt install cpufrequtils) reveals that the 64bit kernel does not yet support intermediate CPU frequencies between 600MHz and 1500MHz.

The new bootloader and both 64bit and 32bit kernels operate without any issues.

Code: Select all

# ./bcmstat.sh 
  Config: v0.5.3, args "MCxgpd1 Tye", priority maximum (-20)
   Board: 4 x ARMv7 cores available, ondemand governor (Pi4 Model B rev 1.1, BCM2838 SoC with 4GB RAM by Sony UK)
  Memory: 1024MB (split 948MB ARM, 76MB GPU) plus 100MB Swap
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  600MHz | 250MHz |   0MHz |   3180MHz   |
Max Freq: | 1500MHz | 500MHz | 500MHz |   3180MHz   |
Voltages: |         0, 0.8688V        |  0, 1.2000V |
   Other: temp_limit=85
Firmware: Nov 19 2019 16:40:28, version aeebba4c03968ede49097db077673eadc2888a22 (clean) (release) (start)
  Codecs: H264 MJPG PCM
  Booted: Fri Nov 29 14:27:28 2019

Time     UFT Vcore      ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s  %user  %nice   %sys  %idle  %iowt   %irq %s/irq %total   cpu0   cpu1   cpu2   cpu3 GPUMem Free MemFreeKB / %used(SwUse)
======== === ====== ======= ======= ======= =============== ====== =========== =========== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== =========== ========================
14:31:28     0.8688 1500Mhz  500Mhz    0Mhz 41.87C (42.84C)  3,470      16,740      15,739   0.00   0.00  36.04  72.07   0.00   0.00   0.00  27.93  27.93  27.93  27.93  45.95  55M ( 98%) 3,793,692 /  7.5%( 0.0%)
14:31:30     0.8688  600Mhz  500Mhz    0Mhz 42.35C (42.84C)    227         227         353   0.00   0.00   1.85  97.92   0.00   0.00   0.00   2.08   2.78   0.00   0.00   4.63  55M ( 98%) 3,794,184 /  7.5%( 0.0%)
14:31:31     0.8688  750Mhz  500Mhz    0Mhz 41.87C (42.84C)    225         283         324   0.23   0.00   1.85  97.92   0.00   0.00   0.00   2.08   2.77   0.92   0.92   3.70  55M ( 98%) 3,793,680 /  7.5%( 0.0%)
14:31:32     0.8688  600Mhz  500Mhz    0Mhz 42.35C (42.84C)    230         225         321   0.46   0.00   2.06  97.43   0.00   0.00   0.00   2.57   2.80   2.80   0.05   5.55  55M ( 98%) 3,793,916 /  7.5%( 0.0%)
14:31:33     0.868

Code: Select all

Time     UFT Vcore      ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s  %user  %nice   %sys  %idle  %iowt   %irq %s/irq %total   cpu0   cpu1   cpu2   cpu3 GPUMem Free MemFreeKB / %used(SwUse)
======== === ====== ======= ======= ======= =============== ====== =========== =========== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== =========== ========================
15:13:30     0.8688 1500Mhz  500Mhz    0Mhz 55.99C (56.97C)    572         276         954  94.56   0.00   5.43   0.00   0.00   0.00   0.00 100.00 100.00 100.00 100.00 100.00  55M ( 98%) 3,365,872 / 17.9%( 0.0%)
15:13:31     0.8688 1500Mhz  500Mhz    0Mhz 56.48C (56.97C)    611         254         384  96.39   0.00   3.54   0.00   0.00   0.00   0.00 100.00 100.00 100.00 100.00 100.00  55M ( 98%) 3,321,436 / 19.0%( 0.0%)
1

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Fri Nov 29, 2019 3:02 pm

Don't forget the 64bit kernel is still undergoing testing, and I suspect it has not yet had the DVFS change applied.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

moriartynz
Posts: 5
Joined: Tue Dec 24, 2019 5:28 am

Re: DVFS Firmware

Thu Dec 26, 2019 3:00 pm

With the December version of rpi-update version f6ae361f091fe2c1b8a2e7d6fa7ae80237884fc3 :

The following settings caused a lock up when starting Xorg:

Code: Select all

arm_freq=1925
over_voltage=3
gpu_freq=600
core_freq=500
The pi boots correctly when the above are commented out. I can also make the pi partially stable (stable for a few minutes) using the DVFS firmware with the following settings:

Code: Select all

arm_freq=2000
over_voltage=6
However, it is not entirely stable and often locks up the Xorg when it starts up and at other times simply freezes everything after a few minutes of use.

My 2c/2p worth in this overclocking debate is that one of the typical stability settings when overclocking an x86/AM64 is to turn off frequency scaling. The reason for this is that changing the clock speed makes the processor unstable if it is pushing its operating frequency envelope. I therefore also urge the developers to switch off DVFS when the CPU/GPU is overclocked or at least to give the overclocker that option. For those users that want a cool-running energy efficient pi, they should not be overclocking anyway as that increases heat output.

Even so, with my non-DVFS firmware previous settings of:

Code: Select all

over_voltage=6
arm_freq=2147
gpu_freq=750
I was using about 6W at idle (at the wall socket using the official Pi power pack) and 7-8W under load. I am using the pi as a low-powered desktop replacement. The setup includes:
  • The overclocked pi 4B (4GB version)
  • a USB-3 attached 128GB SSD (mounted root partition and swap space)
  • a 4-port USB3 hub (not externally powered) with connected USB keyboard and mouse
  • 2 FHD monitors connected to the micro-HDMI ports
  • Small twin fans mounted on a heatsink case
  • bluetooth audio headset connected
  • 5GHz WiFi connection
  • 100% CPU utilisation on all 4 cores for webapps or watching Youtube in Chromium running on Rasbian (if under load).
My mains power meter is not the greatest at reading power usage below about 15W, so those power figures may be subject to errors. For example, it registers zero if not overclocking at idle with DVFS firmware.

My overclock settings (pre-DVFS) were not altogether stable either in that if I ran tesseract-ocr (and some other apps that I can't recall now), it would cause a lockup of the system (screen black and unresponsive to keyboard entry, including <Ctrl><Alt><F1> <Ctrl><Alt><Del>) that required a hard reset. However, if I avoided those problematic apps, then it was pretty much stable all of the time. I could run tesseract-ocr if the pi was not overclocked, so it wasn't a tesseract-ocr software issue.

What would be really cool is if we could change overclocking profiles on-the-fly, so if I run the pi off a battery instead of mains, I can have a script that reverts the pi to no overclocking without a reboot but when mains power is reconnected, we can go back to an overclocked state.

Time for me to revert to a non-DVFS firmware for now methinks.

pica200
Posts: 181
Joined: Tue Aug 06, 2019 10:27 am

Re: DVFS Firmware

Thu Dec 26, 2019 10:08 pm

Regarding stability:
Everything with overvolt higher than 2 and ARM freq higher 1.8 GHz is only semi-stable (no guarantee though). You can test this easily if you use the unsharpen filter in Gimp on large jpg files. It will brownout and reboot if you go too high. There are probaboy other specific instruction sequences which will push it too hard but they are rare (hence why semi-stable).

The sweet spot for rock solid overclocking may vary but i have seen many had success with the above settings.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Fri Dec 27, 2019 7:26 am

Remember that Raspberry Pi do not guarantee ANY overclock settings will work. The facility is provided for people to try overclock if they want, but there should be no expectation that efforts made to reduce power consumption, for example, will not affect overclocking.

We will obviously try not to reduce the ability to overclock, but it's lower priority than improving the device for the majority.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Antima443r
Posts: 2
Joined: Sat Jan 04, 2020 9:13 am

Re: DVFS Firmware

Mon Jan 06, 2020 5:41 am

Overclocking integrated GPU almost always compromises stability, except in special cases where the chip is factory underclocked, i.e. if there is some clock headroom left intentionally. Overclocking iGPU beyond that messes up several things, namely, shared memory timings, shared bus timings and processor power/ thermal budget. It is also not much rewarding in terms of performance, due to low bandwidth and high latency of the shared VRAM already crippling the GPU. In wise words, if you need more gflops in a low power computing platform, change your hardware.

andrum99
Posts: 1025
Joined: Fri Jul 20, 2012 2:41 pm

Re: DVFS Firmware

Mon Jan 06, 2020 5:39 pm

Antima443r wrote:
Mon Jan 06, 2020 5:41 am
Overclocking integrated GPU almost always compromises stability
It works fine for many people on the Pi. The current testing firmware which introduced DVFS is showing regressions in the case where the user has certain overclocking settings - that's the only real issue here. That version of the firmware is not ready for production use anyway.

ktb
Posts: 1443
Joined: Fri Dec 26, 2014 7:53 pm

Re: DVFS Firmware

Tue Jan 21, 2020 3:40 am

I just apt-upgraded one of my overclocked Pi4Bs and it then failed to reboot (stuck at the 4 Raspberry logos). Attempting to boot again completely destroyed the boot partition, just like it did when I had previously tested the DVFS firmware with rpi-update. I had to reformat the boot partition and restore the boot partition files from a backup. So, this DVFS firmware has now hit the main apt repo, correct?

Is there any way to disable it?
Last edited by ktb on Tue Jan 21, 2020 4:41 am, edited 1 time in total.

roslof
Posts: 3
Joined: Sun Dec 08, 2019 5:26 am

Re: DVFS Firmware

Tue Jan 21, 2020 4:32 am

jdb wrote:
Sat Nov 23, 2019 8:23 pm
As it stands, current rpi-update firmware breaks overclocked configurations. You can revert to firmware versions prior to the DVFS implementation by doing sudo rpi-update afbea38042fbb73149ad8c5688c011742fb3ff8a - or by using git hashes from this repo: https://github.com/Hexxeh/rpi-firmware
EDIT: [SOLVED] Was able to rollback with:

Code: Select all

sudo rpi-update afbea38
When I originally tried to downgrade, rpi-update simply said that I was already up to date, even though I was entering the value for the older firmware. Not sure why the git hash worked, but the full value didn't.

ORIGINAL MESSAGE:
jdb (and all), the revert line [from the line quoted] used to work for me, but after performing a standard Raspbian Buster update via sudo apt update and sudo apt full-upgrade, I have the newest 'safe' kernel, but can no longer roll-back with the command listed above. As retro emulation is important to me, and GPU overclocking makes a profound difference in 3D games, was wondering if you are aware of another method of reversion, or if I'm stuck with the newer DVFS kernel.

Best,
ros

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Tue Jan 21, 2020 9:21 am

roslof wrote:
Tue Jan 21, 2020 4:32 am
jdb wrote:
Sat Nov 23, 2019 8:23 pm
As it stands, current rpi-update firmware breaks overclocked configurations. You can revert to firmware versions prior to the DVFS implementation by doing sudo rpi-update afbea38042fbb73149ad8c5688c011742fb3ff8a - or by using git hashes from this repo: https://github.com/Hexxeh/rpi-firmware
EDIT: [SOLVED] Was able to rollback with:

Code: Select all

sudo rpi-update afbea38
When I originally tried to downgrade, rpi-update simply said that I was already up to date, even though I was entering the value for the older firmware. Not sure why the git hash worked, but the full value didn't.

ORIGINAL MESSAGE:
jdb (and all), the revert line [from the line quoted] used to work for me, but after performing a standard Raspbian Buster update via sudo apt update and sudo apt full-upgrade, I have the newest 'safe' kernel, but can no longer roll-back with the command listed above. As retro emulation is important to me, and GPU overclocking makes a profound difference in 3D games, was wondering if you are aware of another method of reversion, or if I'm stuck with the newer DVFS kernel.

Best,
ros
I really cannot see how GPU overclocking make a "profound" difference TBH. Note, there are no guarantees that overclocking will continue to work in the future, the power and temperature control is more important to us as that affects many many more people.

If you only overclock the 3D system rather than the entire GPU, does it work well enough?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

roslof
Posts: 3
Joined: Sun Dec 08, 2019 5:26 am

Re: DVFS Firmware

Tue Jan 21, 2020 11:48 am

jamesh wrote:
Tue Jan 21, 2020 9:21 am
I really cannot see how GPU overclocking make a "profound" difference TBH. Note, there are no guarantees that overclocking will continue to work in the future, the power and temperature control is more important to us as that affects many many more people.

If you only overclock the 3D system rather than the entire GPU, does it work well enough?
Appreciated, James.

Good question. What is the current method of solely overclocking the 3D system with the new kernel?

As for overclocking with gpu_freq on a Raspberry Pi 4B, I stand behind my statement. I've been overclocking for a couple of years and have observed the deltas between stock, CPU-only and CPU/GPU blended performance of games of different types of emulators. When carefully pushed, it can be the difference between a game playing well to perfect, from sub-par at stock. For the GPU specifically, with RetroArch (installed via RetroPie, Lakka, etc.) the Nintendo 64 and Sega Dreamcast games in particular benefit greatly from a boost as low as gpu_freq=600, as they are otherwise GPU starved.

As for "no guarantees" w/overclocking, I understand completely, but I admit it's disappointing. I have mad respect for you guys, but I've been watching this chat carefully, and have been hoping for a change of mindset here. It's hard to stomach when something works well, then is suddenly removed and deemed unimportant. Somebody suggested a toggle for heat vs. performance, and the response was met with it being feature creep [paraphrasing]. I get it though. More Pis being used for non-Retrogaming tasks, so I truly understand your point of view and the decision of the team to push forward with cooling vs. performance.

If it turns out there is a way to overclock the 3D system with solid results, then great! But if not, I'm sure I'm not the only person [in a minority, niche group] willing to forego the update to retain maximum performance, which is too bad. A lot of amazing work is happening here that I'd otherwise love to play with.

Either way, thanks for listening.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Tue Jan 21, 2020 1:17 pm

https://www.raspberrypi.org/documentati ... locking.md

See v3d_freq, assuming it's actually the 3D you need to be a little bit faster, although that is unclear.

Although note that hdmi_enable_4kp60=1 in config.txt will also bump the some stuff in the GPU to 600. Not sure exactly what else is affected.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 292
Joined: Thu Jun 21, 2018 4:30 pm

Re: DVFS Firmware

Tue Jan 21, 2020 1:34 pm

jamesh wrote:
Tue Jan 21, 2020 1:17 pm
https://www.raspberrypi.org/documentati ... locking.md

See v3d_freq, assuming it's actually the 3D you need to be a little bit faster, although that is unclear.

Although note that hdmi_enable_4kp60=1 in config.txt will also bump the some stuff in the GPU to 600. Not sure exactly what else is affected.
600 MHz was the launch firmware, since the September update hdmi_enable_4kp60 uses 550 MHz for the core frequency. 600 MHz core is a lot of extra power for not much gain. v3d_freq is largely independent of core frequency.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Tue Jan 21, 2020 1:46 pm

timg236 wrote:
Tue Jan 21, 2020 1:34 pm
jamesh wrote:
Tue Jan 21, 2020 1:17 pm
https://www.raspberrypi.org/documentati ... locking.md

See v3d_freq, assuming it's actually the 3D you need to be a little bit faster, although that is unclear.

Although note that hdmi_enable_4kp60=1 in config.txt will also bump the some stuff in the GPU to 600. Not sure exactly what else is affected.
600 MHz was the launch firmware, since the September update hdmi_enable_4kp60 uses 550 MHz for the core frequency. 600 MHz core is a lot of extra power for not much gain. v3d_freq is largely independent of core frequency.
Ah, docs need an update then. [Done]
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jgonzi
Posts: 2
Joined: Sun Jan 12, 2020 11:09 pm

Re: DVFS Firmware

Thu Jan 23, 2020 11:16 pm

davidcoton wrote:
DougieLawson wrote:
Sun Nov 24, 2019 8:02 am
You can get it to answer the phone, answer the doorbell and make tea ....
Will it make coffee too? Far more demand for that around here than tea. :? :shock:
Oh, and iced coffee, and hot chocolate... :roll:
Looks like another project to add to my queue. :o :lol: :geek:

(Don't some of our North American cousins go for Raspberry flavoured coffee, and similar absurdities?)
davidcoton wrote:
DougieLawson wrote:
Sun Nov 24, 2019 8:02 am
You can get it to answer the phone, answer the doorbell and make tea ....
Will it make coffee too? Far more demand for that around here than tea. :? :shock:
Oh, and iced coffee, and hot chocolate... :roll:
Looks like another project to add to my queue. :o :lol: :geek:

(Don't some of our North American cousins go for Raspberry flavoured coffee, and similar absurdities?)
roslof wrote:
Tue Jan 21, 2020 11:48 am
jamesh wrote:
Tue Jan 21, 2020 9:21 am
I really cannot see how GPU overclocking make a "profound" difference TBH. Note, there are no guarantees that overclocking will continue to work in the future, the power and temperature control is more important to us as that affects many many more people.

If you only overclock the 3D system rather than the entire GPU, does it work well enough?
Appreciated, James.

Good question. What is the current method of solely overclocking the 3D system with the new kernel?

As for overclocking with gpu_freq on a Raspberry Pi 4B, I stand behind my statement. I've been overclocking for a couple of years and have observed the deltas between stock, CPU-only and CPU/GPU blended performance of games of different types of emulators. When carefully pushed, it can be the difference between a game playing well to perfect, from sub-par at stock. For the GPU specifically, with RetroArch (installed via RetroPie, Lakka, etc.) the Nintendo 64 and Sega Dreamcast games in particular benefit greatly from a boost as low as gpu_freq=600, as they are otherwise GPU starved.

As for "no guarantees" w/overclocking, I understand completely, but I admit it's disappointing. I have mad respect for you guys, but I've been watching this chat carefully, and have been hoping for a change of mindset here. It's hard to stomach when something works well, then is suddenly removed and deemed unimportant. Somebody suggested a toggle for heat vs. performance, and the response was met with it being feature creep [paraphrasing]. I get it though. More Pis being used for non-Retrogaming tasks, so I truly understand your point of view and the decision of the team to push forward with cooling vs. performance.

If it turns out there is a way to overclock the 3D system with solid results, then great! But if not, I'm sure I'm not the only person [in a minority, niche group] willing to forego the update to retain maximum performance, which is too bad. A lot of amazing work is happening here that I'd otherwise love to play with.

Either way, thanks for listening.
I complete agree with you... why take out the option of decision to the user... It is a limitation software made in the firmware. A back step... it seems like big companies when they block their products...

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25017
Joined: Sat Jul 30, 2011 7:41 pm

Re: DVFS Firmware

Fri Jan 24, 2020 7:23 am

It would be useful to know which specific part of the GPU is giving the extra performance required. 3d only? Or one of the other blocks? All of them?

The dvfs changes are complex. Making them selectable is difficult. We may be able to do it at some point, but we are a very small team, with a lot of work to do. This change was necessary as it benefits almost everyone and we needed to get temperatures down.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

dnlzzxz
Posts: 2
Joined: Thu Jan 23, 2020 9:57 pm

Re: DVFS Firmware

Fri Jan 24, 2020 2:48 pm

Well, first congrats for the team for pushing these amazing improvements ... Reducing power consumption and heat is really a great thing for the average user, but a fair share of the user enjoy the thrill of testing and pushing their Pi to the limit. Although I understand the complexity involved, I would like to leave my kindly request to not treat overclocking with a such low priority. The ones who overclock are some of the most passionate about the community/concept of Pi, and it hurts us. Thanks for the efforts and keep up the great job!

Quicksilver
Posts: 4
Joined: Sat Jan 12, 2019 3:10 am

Re: DVFS Firmware

Fri Jan 24, 2020 3:55 pm

jamesh wrote:
Fri Jan 24, 2020 7:23 am
It would be useful to know which specific part of the GPU is giving the extra performance required. 3d only? Or one of the other blocks? All of them?
On the pi 3 it was the core_freq that most benefited emulators that were bottlenecked by the GPU. In my tests increasing the v3d_freq did not increase the FPS for either mupen64plus (n64 emulator) or reicast (dreamcast emulator) but overclocking the core_freq did increase the average FPS for games that dont run at fullspeed already.

I am still running tests on the pi 4 to see if there is any benefit in overclocking the GPU. And if so, which blocks provide the benefit. Ill reports back some specifics once I am finished.

Return to “Advanced users”