iGPU
-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Downloads
Everything posted by iGPU
-
There was another entry to adjust DROMs for TB SSDT files! This one actually works better (and is easier to use), than the one I posted earlier. See this post here. From this post, you can download "HackinDROM". If we can get TB passed, the best fit will probably be the Gigabyte Titan Ridge AIC.
-
When I did the initial install, I set the CPU cores to 32, not the full 64. Aside from the CPU count and arguments, the VM was the same as I used to VM into Catalina. I installed following the directions here, using the recommended VM arguments. I installed directly to the NVMe drive, not a virtual drive, after reformatting the drive. After installation and into the first boot, I then changed the EFI to a more customized EFI, essentially based on the same one used for Catalina and returned the VM to 64 cores. I slightly modified Sherlock's OpenCore EFI by removing his USBPorts kext and ACPI sections, along with adjusting a few other settings. (I keep this modified copy as a "backdoor" boot access should I foul up the main EFI while experimenting.) From what I've read and used, the Big Sur boot EFI requires more settings than the installation EFI, such as -lilubetaall and vsmcgen=1 along with the NVRAM/Delete 'booster' entry shown below: The above settings were needed for v060 from 28 June. Supposedly, these settings are not required for v060 5 July. However, as I previously posted, I cannot get this latter v060 to boot. Since most kexts won't load, it didn't matter which ones I had enabled or disabled. I did leave most of the ACPI's disabled. And since I can't load the Ethernet kext, I'm passing a virtual network. I have no BT, so keyboard and mouse are hardwired. Since it's such an early beta, many small things are missing, but not unexpected and not worth discussing in detail.
-
Yesterday, I read one of the more significant updates to our understanding of TB. It's related to how the DROM section, which is critical for proper functioning of the SSDT, is constructed. A new tool was uploaded and discussed in detail here by CaseySJ (who is a true guru for TB; all firmware flashing I did was based on his work). There is also an interesting post he made on same page as the link, but 2 posts up. I updated some of my SSDT TB DROM using this tool; all needed improvement. (Morganaut copies off the internet the work of others and charges for her collation. We should share without charge; accordingly, I have no use for her posts.)
-
I agree that Mojave has a lot going for it, and seems to be one of the more stable macOSs (while Catalina, at least until the latest ß-releases, was one of the least stable). As for X570, I finally gave up on that platform (I gave the working build to a family member). The X570 chipset has too many issues with lane-sharing (which I finally figured out and posted on the old AMD forum; I created a GitHub for that build, from which many have used the SSDTs for other X570 builds). Intel shares PCIe lanes with SATA; AMD chose in the X570 to share lanes with the NVMe slots, a problem that was further compounded if TB was enabled (TB was placed in the same group of lanes). Meanwhile, we don't see those issues with the TRX40 chipset. Since I turned off the WiFi on this build, the computer running under Proxmox has been very stable and I get no audio dropout (I'm using a USB-interface). When WiFi was enabled, the computer would freeze within 5 min. I've now left the computer running 24/7 for over one week with no issues running the latest Catalina ß. I've now even booted into Big Sur on a spare NVMe drive, and it's been running for 24/7 for 3 days without any problems. Well, one problem. I can't get any kext files to load. I'm using OC v060 from 28 June and it boots; if I change to 5 July v060 (which supposedly better loads kexts), it won't boot, but panics. I'm still investigating. The main limitation of this build to date, is the Linux-related restriction of passing-through various PCIe devices. If such devices are critical for your work, like perhaps some of the RME PCIe boards, then it could be a no-go; you have to test each card to know if works. My findings with some USB AIC led me to discover that manufacturing changes over time led one card, which had been usable for pass-through, to becoming unusable as it now would not pass-through due to those manufacturing changes. Unfortunately, only the more recently manufactured USB AIC are available for sale. (I'm a bit surprised that Linux hasn't addressed these issues as complex PCIe AICs have been used for a number of years.)
-
I don't understand how OpenCore can access Thunderbolt on a motherboard: it's a boot-loader. And I don't think I'd refer to a TB card as "external" (such as TB-based eGPU external enclosures), since it's plugged into a PCIe slot. When I used the ASRock X570 Creator, I had the motherboard TB working (to my knowledge, I was first to get it working and posted on CaseySJ's thread; the original SnazzyLab thread in the old AMD Forum in Jan of this year). Besides trying to flash the TB chip on the mobo, I actually de-soldered it and tried replacing with flashed chips. I only had partial success with this method. I finally gave up on the ASRock and transferred the 3950X chip over to a Gigabyte X570 Aorus Master mobo (which happens to have a TB header), and used a flashed TB AIC to get a proper TB tree and full functionality. So working and having full TB functionality with a proper TB tree are two entirely different things. Unless flashed, I don't believe any TB devices have a proper TB tree and full functionality running in a Hackintosh. However, a partially working TB device on a Hackintosh can be created by a good SSDT (and again, I don't see how a boot-loader can activate a TB device; it makes no sense to me). Full TB functionality with a proper TB tree requires flashing and a good SSDT.
-
Yes, fabiosun is correct, some months ago, I had TB3 working with add-on cards (such as the Gigabyte Titan Ridge AIC, but with flashed firmware after CaseySJ) on the X570 platform. However, I was not able to directly flash a Thunderbolt chip on the motherboard, but only on an AIC. On the VM side, the problem as I've posted earlier in this thread, is different. The problem here is that on Linux VMs (Proxmox or any other distro), one cannot pass the pci-bridge components from host to guest. Without the complete device, the device cannot work in the host VM. This not only applies to Thunderbolt cards, but also USB and FireWire cards that contain bridge structures. Once Linux allows pass-through of a complete device, then Thunderbolt and other devices should work just fine under a VM.
-
There is little reason to think that Proxmox settings for a Mac VM would need changing based on the OS version. The changes, if any, would more likely be in the boot loader section as fabiosun showed in the above post. Since Big Sur is a natural upgrade from Catalina, settings used in Catalina would be a reasonable starting point. A more significant issue is what software now used won't properly work in Big Sur.
-
I wanted more USB ports, esp on desk, so I added this USB hub. It features 7 switchable USB3 ports and 4 charging ports. I have the hub plugged into one of the rear panel ports on the MSI Creator mobo. It comes with an attached USB cable and power adapter. Between the hub and the mobo, I added a USB extension cable since the mobo is almost 2m from desk.
-
When tested running WIndows 10, I never saw temps over upper 70s; definitely below 80°C. When running macOS, I have CPU fans on radiator set at about 600 rpm until 60°C, then increases to 800 rpm until 80°C, then 1200 rpm until 90°C, then 1600 rpm. The pump similarly is constant and increases after 85°C. I never notice a loud fan or pump during Cinebench tests, so this confirms temps below 80°C under macOS as well.
-
I've heard recommendations to set in BIOS for improved stability (same issue but different tabs for MSI mobos): 'Power Supply Idle Control' from 'Auto' to 'Low current idle' (rather than 'Typical'). Personally, I'm not certain that I've noticed a difference.
-
You're absolutely correct! Project was set at 1080p @ 24 fps. I re-set to 1080p @ 120 fps, and then saw a maximum of 35 fps (typically 28-32) when running both Radeon VIIs.
-
fabiosun, You previously asked about running the 2-Candle test in DaVinci Resolve with two Radeon VIIs. I finally got around to testing. Presently, neither WEG nor RadeonBoost is enabled, and no GPU DeviceProperties are being injected, so everything very stock. In DaVinci Resolve, the GPU Preferences were set to Auto with both GPUs active; 66 nodes were left active (the maximum). macOS was Catalina 10.15.6-ß2. When one Radeon VII is used, the result was 16 fps. From my searches, this is a typical result for one Radeon VII (and the same result commonly observed when using one 2080 Ti). When using two Radeon VIIs, the result was 24 fps as shown below 35 fps. I plan on converting both Radeon VIIs to water-cooled in a week or so and will then overclock them and re-test.
-
Yes, I tried and posted rear panel once or twice before. I'll repeat here again. Since we're all using TRX40 mobos and the TRX40 chips are designed by AMD, all of the mobos will have a similar pattern (the exact x-value of x.1 and x.3 will vary). The x.1 is for the audio and the bulk of the the rear panel USB ports. While x.3 is for BT and the internal USB headers. (Note the internal USB3 headers listed at top.) I chose not to pass-through any 4:00 or 25:00 devices. If you feel that the audio is a problem and you do NOT want to pass x.1, then you might consider adding a part like this, connected to an internal header (x.3). Such an expansion header will provide extra USB ports on the rear panel (but occupy one PCI slot), which would otherwise be absent if x.1 were not passed. MSI Creator Rear Panel:
-
I've repeated tests with ArcoLinux (and re-verified in Proxmox): both ASMedia as well as 48:00.0, 48:00.1 and 48:00.3, can be pass-through, and still have proper USB audio with no audio dropout, as long as WiFi is disabled. I think I'd not initially noticed this phenomenon (if one looks at my original posts on this thread), as I was using the native BT/Wifi card with only the BT enabled. This is becausae WiFi on native AX200 cards has, as yet, no known kexts to activate WiFi on the macOS side. So I had unintentionally inactivated WiFi and good USB Audio with no dropouts. So possibly, when one is using the TRX40 mobos with a Mac VM, one will need to make one of two choices. That is, based on what you've indicated and what I've found with WiFi, if USB ports and BT are more important and WiFi is not, then pass-through all USB devices but inactivate WiFi and the USB audio/FireWire audio should be okay. On the other hand, if WiFi is necessary, then don't pass-through 48:00.x, and have fewer active USB ports and no BT, but functional WiFi. *** As for PCIe AIC USB cards, I've not posted this to date on this forum, but I've not yet found a card that works on a VM with pass-through, and I've tried many (just as I've not yet gotten a working FireWire card: one more is on order!). If one Googles on "PCIe AIC USB cards pass-through VM", one can find several threads discussing this issue, particularly starting in 2017. There are references to a few expensive cards, but once one then researches those cards, there are further posts saying that those cards have been modified over the past 3 years of production, and don't always work in a pass-through environment. This is the same situation I faced with FireWire: newer cards are re-designed and now contain a bridge that prevents VM pass-through. But if you were seeing erratic behavior of your PCIe FireWire card when 48:00.3 is active, then a PCIe USB card will most likely suffer the same fate. This would mean, again reverting to my high-lighted paragraph above, where one must make a choice between USB ports and BT or WiFi for proper audio.
-
For the past couple of weeks, I've been playing with getting a VM working on ArcoLinux while, in parallel, working on problems in Proxmox. I did this to check on 2 issues: getting Thunderbolt to work and getting rid of the USB dropout problem. The potential advantage of ArcoLinux, unlike Proxmox or UnRAID, is that it gets the latest kernels; maybe a year or two faster than Proxmox or UnRaid. I've finally got a Catalina VM working (see image below). However, I've not yet passed the GPUs and I'm presently only passing 8 cores to the macOS VM. While the installation of ArcoLinux is simple and not much different than Proxmox, setting up a VM is more involved. In ArcoLinux, there is more support for VirtualBox (which doesn't seem to want to play nicely with macOS), but Virt-Manager seems to be a more flexible choice. However, it takes a few more steps to get it working. (I did not document what is involved, nor do I plan on presenting a tutorial; this post is more of an FYI.) Once Virt-Manager is installed and the usual vfio files are created (same as with Proxmox), running the VM is straightforward. There are a few differences, such as the devices seen with IORegistryExplorer having different addresses, which appear more ordered. (I'll later update an image or two to this post.) As with Proxmox, I was not able to get Thunderbolt working for the same reasons: no ability as of yet to pass the bridge portions. Although, I thought I'd read that in the near future, the Linux kernel will allow passing whole devices. (And since ArcoLinux kernels seem, a VM running under ArcoLinux might be expected to pass TB before other distros.) With regards to the USB audio dropout problem, it is about the same as with Proxmox. However, I was able to noticeably reduce, if not eliminate, the dropout by turning off BT and WiFi. (I tried this once before in Proxmox and did not notice an improvement; but I'll revisit it again.) Catalina VM under AcroLinux:
-
Both BT and Wifi work on the swapped card if you use all the kexts I indicated. (The first is for WiFi, the others for BT.) If this doesn't work, then: 1. don't have the card properly seated in its socket 2. the antennas are not properly connected to the card or the rear panel 3. you didn't pass the USB power for BT (I wrote about this once or twice on this thread) On the other hand, as I posted on this thread, if you ONLY need BT, then the stock BT/Wifi card (no swap needed) works just fine if you use the 2 kexts I uploaded earlier on this thread.
-
Thanks for reply. I have this issue whether Mojave 10.14.6 or latest Catalina 10.15.6-beta2. I'm not using any built-in audio, but instead a USB-interface that is plugged into a USB-port. All ports seem to behave the same with these drop-outs. BTW, I do NOT see this problem when running ArcoLinux on this same mobo with same USB-interface, nor do I see it with Intel Hackintoshes using same interface. So this problem is most likely related to the VM and USB ports.
-
Yes, AppleALC provides HDEF seen in IORegistryExplorer, so I continue using. My list of kexts are: Essential: Lilu VirtualSMC (a branch of FakeSMC + GPU support kext is better for getting temps off of a Radeon VII) Used: AppleALC----------------------------needed for HDEF / HDMI AirportBrcmFixup----------\ BrcmBluetoothInjector----\ BrcmFirmwareData---------|---needed for swapped BT/Wifi card (some users don't need these; I have no BT if they're not present) BrcmPatchRAM3------------/ BTLEContinuityFixup-----/ SmallTreeIntel2576--------------needed for I211 Ethernet (different kexts needed for different Ethernet controllers) Used (with mixed feelings): WhateverGreen (when enabled does cause issues with 5700XT and Radeon VII on Intel platform; not necessarily same on VM) Potentially useful (but not yet vetted for this VM): NVMeFix RadeonBooster (v1.6) Not used (but could be useful in future if modified for Threadripper): AMDRyzenCPUPowerManagement SMCAMDProcessor *** While the build now seems stable, I am experiencing audio drop-out (duration 0.5 to 5 seconds) while watching YouTube using a USB Audio Interface. I want to proceed using this build for a Davinci based video project I'm working on. The audio interface is required for recording, so fixing the drop-out is important. It is not a regular drop-out, but somewhat random in frequency. I'm trying various remedies. Varying the USB ports (whether ASMedia USB-C or stock) does not help: drop-out is the same. Some areas to yet check are disabling BT and WiFi, along with trying some of the USB related efi driver files provided with OpenCore builds.
-
For the past couple of weeks, both Mojave and Catalina have been unstable for me on this VM. After logging in, I often didn't see a background image; instead, only a black background was present. The normal background would pop into view after a few minutes. If I did a Re-Start, the background would instantly (normally) appear. Also, after the background popped into view, the mouse cursor would eventually disappear and the computer would lock-up, forcing a shutdown. There was no correlation with AppleALC or WEG kexts. I had no stability issues if running under Console mode; instability was only present when passing the GPU(s). Now, I finally seem to have stability... The critical steps for me were: 1. cut out some of the SSDTs that I was using to rename devices (a habit I've picked up from bare-metal builds). When present, boot time is prolonged. 2. replace my power supply (I don't think the brand is as important as simply having a good one). I normally used EVGA, but this last one was a lemon. 3. reluctantly, I added 'blacklist amdgpu'. This was probably the most important step for stability. It also fixed the missing background on log-in as well as making the boot time much faster when the GPUs were being passed. Unfortunately, when blacklist amdgpu is used, the host monitor output disappears. As long as the GUI interface works, this isn't a problem. But as I found out a few weeks ago, after moving the Proxmox NVMe drive to another slot, the GUI can also disappear. When that happens, you're totally locked out. The only solution is to then do a Proxmox re-install.
-
Another source of USB problems may be Catalina... To quote this link: "Apple has a USB 2.0 issue with either the chipset they are using, or a Catalina bug regarding the handling and refreshing of USB 2.0 devices....Transparent proxies take the USB 2.0 input and present it as USB 2.0 to the MacBook Pro. The Mac or Catalina then will do something wrong and the USB 2.0 devices will freeze / become unresponsive at some point (minutes or hours after being attached)." *** I'm still experiencing problems with stability that I'm working on (hence my silence). I'm trying to further sort out issues one by one. (And Newegg sent me the exact same Firewire card I'd already tried from Amazon. Newegg's ad showed the older style card, but that's not what they shipped; so it went back.)
-
I don't know if it holds true for these VM builds, but on typical, bare-metal Hackintosh builds, USB problems have been associated with faulty Power Supplies. If you have another PS (and better yet, a different brand), it might be a useful test to swap out your current PS to see how this affects your USB functionality.
-
I posted this information several days ago here.
-
When trouble shooting, you want to keep things as simple as possible. For me, this means not passing any GPU, but staying in Console mode in the GUI. Also, I'd not pass any USB audio or SATA devices, but instead only pass the minimum: keyboard/mouse USB, Ethernet port, and your NVMe drive (I think I read you already have this created and have a proper EFI installed on it). When commenting out the GPU address in the VM config file, remember to also reset "vga: none" to "vga: vmware". It also seems useful to have "tablet: 0". And if you're booting directly to your NVMe drive, have "boot: d" (not "bootdisk: ide2"). The next item to check is your blacklist config file (nano /etc/modprobe.d/blacklist.conf). It needs very little. I'm only entering in this file: blacklist nouveau, blacklist nvidia, and blacklist nvidiafb. Do not enter "amdgpu" else you can shut down terminal entry on the host side. Another problem you might be having is which drive you're actually selecting in the Proxmox opening window (see Spoiler below). Press <Esc> key during progress bar to enter and be able to select the boot drive (it should be your NVMe's EFI partition). Within this you can also use the Boot Manager to permanently fix the selection so it will automatically, correctly select the proper drive each time you boot the VM. (I would also not auto-boot until all things are running perfectly; that is, "onboot: 0", not "1".) Once you can successfully boot and fiddle around in macOS at this stage, then go back into your VM config file and re-set items to pass the GPU. Once that's working, the address USB and SATA issues. Your signature indicates that your primary GPU is the 5700XT. This GPU has had some issues with black screens in Catalina. You should probably have in OpenCore, the boot argument "agdpmod=pikera"; this has been helpful for some 5700XT users. The black screen problem has been particularly keen during Catalina install in those using the 5700XT (as I recall, esp for the 10.15.4 release).
-
I think one of the best, and not too expensive, if modified (there are on-line references as to how), is the one I referenced earlier in this thread (here) and is in my signature.
-
I found this model at Newegg in the US (thanks). One more time...
