Jump to content

23d1

Donator
  • Posts

    97
  • Joined

  • Last visited

Everything posted by 23d1

  1. Got the same CPU, and I do tend to run at stock clocks, as I favor stability equally with power, for longevity with intent to have my workstation do its job for 5-7 years (about what one gets out of a Mac Pro before becoming too obsolete). Getting similar results here, though with SMT enabled in Windows the results are off the charts. Over 64000 for stock and beyond 78000 when enabling PBO (which makes my desktop lamp flicker, hah) drawing about 600W.
  2. I notice you're using SSDT-SBRG-USBX.aml and SSDT-PLUG.aml, are those potentially helpful with Shutdown/Restart? I've sorted out all my MMIO stuff and have tried the disable rtc checksum, but same issues persist (which according to OpenCore docs are related to RTC, but I have a weird hunch it might be a PowerManagement thing either relating to CPU or USB/ports). Only thing left for me to try besides that is DummyPowerManagement, I suppose. @Driftwood any updates on your end in relation to Sleep/Wake and Shutdown/Restart? Same mobo here, and your config.plist was instrumental to my success. 🙂
  3. While sleep is not possible with SMT off, I wonder if anyone has a solution to restart/shutdown issues? I seem to be able to shut down and restart the machine, however it doesn't post, so it just spins with no video output. I have to turn it off on the PSU and powercycle after a shutdown/reboot.
  4. I think you're right. 😉
  5. Sure thing! These benchmarks were all done at base clock/boost, without PBO enabled. Pretty much almost on par with Windows with SMT (multithreading) off. With multithreading on, Cinebench in Windows nets about 64,000 points, and with PBO that shoots off the chart beyond 78,000 points. Now if I can figure out a way to recompile the kernel and get some help with the AppleACPIPlatform.kext to support 128 threads, I think we may be able to see the same results as in Windows/Linux. In regards to the 6800XT the benchmark scene for Redshift finishes in 4m6s, which is about the same as using two 1080Ti in Windows/Linux. Amazing performance compared to eGPU on MacBook Pro, where Apple Metal seems to add some overhead for some reason, resulting in about 30% performance loss...
  6. The kernel seems straightforward enough, but yeah—I wouldn't even know where to start with modding kext and so forth. My cooler can take it, but I'm about longevity as well—so I typically run at base clock/boost unless I need the extra power for a sim or CPU rendering. Would be fantastic if Apple raised the core count on their end in general, but unlikely for x86, I'm assuming—more likely for ARM.
  7. As a side note, the AMD RX 6800 XT is in par with 2 x 1080 Ti overclocked. At about 4 minutes Redshift Benchmark, which is a HUGE improvement compared to eGPU AMD RX 6800 XT connected to a MacBook Pro, that clocks in at over 5 minutes. Add one or two 6800 XT or 6900 XT and overall, this is the fastest Mac known to man. Boom!
  8. After further testing, the true performance falloff seems to be about 15%... It's a lot better than 25-30%, and in line with turning off SMT (Hyperthreading) in Windows and Linux. It's a shame macOS can't take more than 64 threads, because my machine would be crushing it in the top with PBO (AMD Precision Boost Overdrive) enabled—as I'm getting close to 80k points in Cinebench in Windows.
  9. Yes, SMT (Hyperthreading) is disabled in BIOS, but I had virtualization set up in BIOS to be able to pass the host CPU to VMs, and that was tripping up the PowerManagement in macOS. The weird quirks/variables for booting and running macOS are many (to say the least). In hindsight, I can't believe this wasn't one of the first things to test... I just automatically assumed that it wouldn't play a role in the grand scheme of things (most advanced operating system my ass). I probably need to update my MMIO config after this... 😅
  10. Simply changing the topology in Kernel > Patch from BA20... to BA40... (hexadecimal for 64 is 40) only cosmetically changed the reading. Had a hunch that NUMA/Virtualization may have been an issue, as PowerManagement couldn't detect the CPU states, more or less. Said and done, I disabled those in BIOS (wanted those intact for the times I do boot Linux or Windows to virtualize macOS), and now only about 10% performance drop on bare metal. Amazing. The AMD Power Gadget App is now showing the frequencies being altered on the fly. Sick! About 62,000 points in Cinebench (78,000 in Windows, though) but in general a lot closer to "native" performance.
  11. Coming back to this thread about the 3990x. No progress, but I've found Geekbech results that reference the topology set to 1x64cores, whereas mine reads as 1x32cores64threads. Is there a way in OpenCore to specify the topology? I'm curious if that's where the issue lies in PowerManagement, since the results are indeed closer to 3970x, while I've seen Geekbench results referencing much higher results (similar to Windows/Linux). Any ideas? If I can sort this out, I think this bare metal boot would be my daily driver. Edit 1; simply changing the topology in Kernel > Patch from BA20... to BA40... (hexadecimal for 64 is 40) only cosmetically changed the reading. Curious how some seem to have managed to tap into the full potential of the 3990x in macOS. Edit 2; had a hunch that NUMA/Virtualization may have been an issue, as PowerManagement couldn't detect the CPU states, more or less. Said and done, I disabled those in BIOS, and now only about 10% performance drop on bare metal. Amazing. The AMD Power Gadget App is now showing the frequencies being altered on the fly. Sick! Will post in the separate thread as well. NICE!
  12. While bare metal is slow on Big Sur compared to KVM passthrough (where voltages and clocks are handled by linux as opposed to macOS), it's almost equal in Monterey, so there seems to be some underlying changes in macOS. Will do a more in-depth comparison when I have a moment, but I think it's safe to assume that the same issues persist, where the 3990x clocks remain flat at 2.9Ghz, instead of boosting up to the factory boost clocks of 4.3Ghz. Funny enough, it's still about twice as fast as the top tier Mac Pro from Apple, but it could theoretically by more than 3 times as fast, as it is in Linux/Windows.
  13. Yep, read up on the posts. Strangely, I cannot get into macOS if I set the SecureBootModel to anything but disabled now. Very odd. So no way to upgrade to RC2.
  14. For some reason, I'm not seeing the update(s). I just added the beta profile and upgraded from Big Sur, pretty smooth, but the version is 21A5552a (Beta 10), and the RC1 (21A558) is not showing up. I've got SecureBootModel set to Disabled as I can't boot otherwise, is there another tweak I'm missing? Oops. Seems to work changing the SecureBootModel to "j160", corresponding to the MacPro7,1. I'll leave this comment up in case someone searches for a solution.
  15. Reporting back; disabling half of the cores and leaving multithreading on didn't change any base/boost frequency control on the macOS side. Cinebench r23 came back at about 30,000 points, which makes sense considering we're losing 32 physical cores. CC: @fabiosun Might be something that is patchable through kernel or otherwise, but hard to say, obviously. Current conclusion; everything is super smooth and works great regardless of the fairly massive performance drop compared to fully threaded in Win/Linux. To be able to tap into some of that extra juice, KVM is the way to go with 3990x at this point. Unless you're doing highly threaded workflows (CPU based 3D rendering, simulation, and so forth), Bare Metal is the smoother experience compared to KVM which has it's quirks to iron out.
  16. Next step I'll try disabling cores and report back, to see if it's a matter of how macOS handles single-threaded vs multi-threaded, or if it's just a lack of support for 3990x in general.
  17. Starting this thread from a discussion in the Bare Metal Vanilla thread. The TL;DR: There seems to be a lack of power management, or rather a lack of frequency management in macOS when it comes to the 3990x 64 core (128 thread) processor. Since macOS can only handle 64 threads, one has to either disable cores or disable multithreading. The CPU clock remains static at base 2.9Ghz, never moving up or down (the stock boost frequency is 4.3Ghz). After exhausting many options with kexts, tweaks in config.plist, and BIOS settings my theory is that either macOS has no instructions for managing CPU frequencies for processors running single threaded, or there's just not been enough research as it's an overkill CPU for macOS in general. The ideal situation would be macOS supporting 64-core/128-thread processors, but I doubt that will happen for anything other than ARM/Apple Silicon...
  18. So you mean disable cores? Hmm. I thought disabling multithreading would simply make macOS "think" it was 32+32... Damnit, they need to add support for more cores in the system. Will look at the MMIO, must have been a setting I missed when defaulting the bios.
  19. Isn't it technically 64+0? In Windows is 64+64, with 64+0 I land around 60000 points. I would settle for at least what I get through VM. 😅
  20. I've actually tried. I first added just the AMDRyzenCPUPowerManagement.kext naively hoping that would fix my problems, then SMCAMDProcessor.kext, and it's all the same with or without. I have noticed that TDP actually goes up to 280W, I think it just happens when fully loaded at 2,9GHz and Cinebench doesn't really saturate the CPU for some reason, so it goes to about 270W. In either case, the clock remains unchanged. With PBO on in windows I get over 76000 points, and in macOS I hover around 41000-43000, no change in general, not even with PBO on. Huge performance loss, even greater with PBO on. In VM I get about 54000 points in macOS—but no sound at all. Hah.
  21. Here's the new log... I guess this does stand out (also in previous log); 00:519 00:010 OCCPU: Failed to get FSBFrequency data using Apple Platform Info - Not Found FSB is the clock frequency multiplier, if I'm not mistaken. Which is displayed earlier in the log; 00:116 00:001 OCCPU: CPUFrequency 2899992542Hz 2899MHz 00:117 00:001 OCCPU: FSBFrequency 103571162Hz 103MHz opencore-2021-10-15-071057.txt.zip
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.