View Single Post
Old 2020-10-20, 16:45   #10
M344587487
 
M344587487's Avatar
 
"Composite as Heck"
Oct 2017

3×263 Posts
Default

Quote:
Originally Posted by aheeffer View Post
I wrote these down from a Radeon VII forum but forgot to save the link:

fp32 13481
fp64 3417
Thanks, 1:4 ratio it is.
Quote:
Originally Posted by chris2be8 View Post
Try running the live CD with the NVMe plugged in but not being used, and compare power draw with when it's not plugged in. That should isolate its power draw. You probably want to compare both cases when the system's idle and when it's under load (see if the difference between idle and busy varies if the NVMe is there).

Chris
I'll revisit NVMe when Ubuntu 20.10 is out in a few days and try what you suggest. Trying to get the iGPU running nicely ATM which is trickier than it sounds.
Quote:
Originally Posted by henryzz View Post
I believe .net core is much better at running on linux
It probably is, I'm just stubbornly against the entire ecosystem as I've been burned too many times. If I had a penny for every community tool I've encountered that doesn't have source (or does but it's not written for core) and only has a windows .NET binary that absolutely fails in wine even if you use MS's libraries that you need to accept their EULA for, well I'd have a handful of pennies but it's very annoying. EXE tools written in C/C++ tend to work flawlessly under wine unless they interact closely with the hardware. I'd prefer a community tool be written in java than .NET which is saying something.

iGPU debugging
Did a mfakto run with stock settings but found that the iGPU endlessly cycles between being occupied for ~10 seconds then dropping to its minimum frequency for a few seconds, a run completed in 1h37m. mfakto live output shows 110 GHz-d/day at high frequency and 55 GHz-d/day at low frequency, wall power is 5-6W at low frequency so the chip must be using very little power then. Searching suggests that perhaps there's a bug with the VRAM/RAM split, using more than the 512MiB dedicated to the GPU means relying on the OS to manage it dynamically and it apparently can bottleneck somehow. Unfortunately my bios doesn't expose the split as a variable so it's fixed at 512MiB. To try and confirm that going into dynamically allocated memory is what's causing the cycling I'm setting an upper vram limit using amdgpu.vramlimit=x as a kernel boot parameter (default is vramlimit=0 meaning no limit):

Factor=77936863,71,72 tests:
Code:
       Boot Parameter   Time (M)
amdgpu.vramlimit=256           83
amdgpu.vramlimit=448           85
amdgpu.vramlimit=512          122
No boot parameter            97
vramlimit of 256 and 448 acted similarly, with the minimal frequency still being used but for much less time relative to no vram limit with live output most often sticking to 110 GHz-d/day but going up to as much as 134 GHz-d/day. There's still cycling but improved throughput. vramlimit=512 is an odd result that I might investigate further at a later date (longer stretches of minimal frequency and no boosting beyond 110 GHz-d/day), it could be that it has the worst of both worlds (not enough RAM but enough to trigger a dynamic allocation bug). There is a lot of variability so the tests are only ballpark but they show a trend. Setting vramlimit to 511 or below spams dmesg with errors like below but the tests complete fine, probably due to setting vramlimit below the amount dedicated to the GPU:
Code:
[ 3581.454872] ------------[ cut here ]------------
[ 3581.454974] WARNING: CPU: 0 PID: 2178 at /var/lib/dkms/amdgpu/3.8-30/build/amd/amdgpu/amdgpu_gmc.h:265 amdgpu_cs_bo_validate+0x196/0x1c0 [amdgpu]
[ 3581.454977] Modules linked in: ccm nls_iso8859_1 rtsx_usb_ms memstick btusb btrtl btbcm btintel bluetooth joydev input_leds ecdh_generic ecc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel tps6598x snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm iwlmvm snd_seq_midi snd_seq_midi_event mac80211 edac_mce_amd snd_rawmidi libarc4 kvm_amd ccp kvm snd_seq crct10dif_pclmul ghash_clmulni_intel snd_seq_device aesni_intel ipmi_devintf iwlwifi crypto_simd snd_timer wmi_bmof cryptd k10temp ipmi_msghandler eeepc_wmi glue_helper asus_wmi sparse_keymap snd_rn_pci_acp3x snd cfg80211 soundcore snd_pci_acp3x ite_cir rc_core ucsi_acpi typec_ucsi typec i2c_multi_instantiate mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) zlua(PO) rtsx_usb_sdmmc rtsx_usb hid_generic usbhid amdgpu(OE) amd_iommu_v2 amd_sched(OE) amdttm(OE) amdkcl(OE) i2c_algo_bit drm_kms_helper
[ 3581.455027]  nvme syscopyarea sysfillrect crc32_pclmul sysimgblt fb_sys_fops ahci drm i2c_piix4 libahci nvme_core r8169 realtek wmi video i2c_hid hid
[ 3581.455038] CPU: 0 PID: 2178 Comm: Xorg:cs0 Tainted: P        W  OE     5.4.0-51-generic #56-Ubuntu
[ 3581.455040] Hardware name: ASUSTeK COMPUTER INC. MINIPC PN50/PN50, BIOS 0416 08/27/2020
[ 3581.455137] RIP: 0010:amdgpu_cs_bo_validate+0x196/0x1c0 [amdgpu]
[ 3581.455142] Code: ff 77 42 74 1d f6 83 b8 02 00 00 01 74 14 49 8b 86 c0 00 00 00 49 39 86 d0 00 00 00 0f 83 ef fe ff ff 44 8b 03 e9 eb fe ff ff <0f> 0b e9 2f ff ff ff 8b 53 04 44 39 c2 0f 84 77 ff ff ff 41 89 d0
[ 3581.455143] RSP: 0018:ffffad61844c7a20 EFLAGS: 00010206
[ 3581.455144] RAX: 0000000000000000 RBX: ffff9be9a2b1ac00 RCX: 0000000010000000
[ 3581.455146] RDX: 0000000000000001 RSI: 0000000000040002 RDI: 0000000000000000
[ 3581.455147] RBP: ffffad61844c7a78 R08: 0000000000000002 R09: ffff9be9a2b1ac14
[ 3581.455148] R10: ffff9be9ef417848 R11: 0000000000000000 R12: ffff9be9a2b1ac50
[ 3581.455149] R13: ffff9be9a2b1ac30 R14: ffffad61844c7b80 R15: ffff9be9d95e50a0
[ 3581.455150] FS:  00007fc891a42700(0000) GS:ffff9be9ef400000(0000) knlGS:0000000000000000
[ 3581.455152] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3581.455155] CR2: 000055ad591d7fe4 CR3: 00000007a467e000 CR4: 0000000000340ef0
[ 3581.455156] Call Trace:
[ 3581.455254]  amdgpu_cs_validate+0x17/0x40 [amdgpu]
[ 3581.455354]  amdgpu_cs_list_validate+0x100/0x140 [amdgpu]
[ 3581.455454]  amdgpu_cs_ioctl+0x1a55/0x1f00 [amdgpu]
[ 3581.455557]  ? amdgpu_cs_find_mapping+0x120/0x120 [amdgpu]
[ 3581.455577]  drm_ioctl_kernel+0xae/0xf0 [drm]
[ 3581.455594]  drm_ioctl+0x234/0x3d0 [drm]
[ 3581.455694]  ? amdgpu_cs_find_mapping+0x120/0x120 [amdgpu]
[ 3581.455792]  amdgpu_drm_ioctl+0x4e/0x80 [amdgpu]
[ 3581.455798]  do_vfs_ioctl+0x407/0x670
[ 3581.455802]  ? do_futex+0x160/0x1e0
[ 3581.455806]  ksys_ioctl+0x67/0x90
[ 3581.455808]  __x64_sys_ioctl+0x1a/0x20
[ 3581.455811]  do_syscall_64+0x57/0x190
[ 3581.455815]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 3581.455819] RIP: 0033:0x7fc89834350b
[ 3581.455820] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48
[ 3581.455821] RSP: 002b:00007fc891a41868 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 3581.455823] RAX: ffffffffffffffda RBX: 00007fc891a418d0 RCX: 00007fc89834350b
[ 3581.455824] RDX: 00007fc891a418d0 RSI: 00000000c0186444 RDI: 000000000000000d
[ 3581.455825] RBP: 00000000c0186444 R08: 00007fc891a41a20 R09: 0000000000000020
[ 3581.455826] R10: 00007fc891a41a20 R11: 0000000000000246 R12: 00005606f5538940
[ 3581.455827] R13: 000000000000000d R14: 00005606f55f4c2c R15: 00005606f55eca38
[ 3581.455829] ---[ end trace f6219db7c8930d05 ]---
There is another boot parameter vis_vramlimit=x which can be used to limit how much dynamic memory is used, haven't investigated it yet. The default of 0 means unlimited so am unsure how to set dynamic memory to zero. Logically dynamic memory use should naturally be 0 if vramlimit is set to 512 or less but there may be shenanigans.
M344587487 is offline   Reply With Quote