Jump to content

KGP-iMacPro

Members
  • Content Count

    696
  • Joined

  • Last visited

About KGP-iMacPro

  • Rank
    InsanelyMac Legend

Profile Information

  • Gender
    Male
  • Location
    Berlin, Germany, Europe

Recent Profile Visitors

5,945 profile views
  1. New createInstaller.sh scripts for macOS Mojave 10.14.4 (18E226) and macOS Mojave 10.14.4 (18E2034) - special buildApple recently changed the index for macOS Mojave 10.14.4 (18E226) on http://swcdn.apple.com/, although resulting Install macOS Mojave.app version remains 14.4.08. I therefore expect the respective macOS Mojave 10.14.4 build still to be 18E226.Respective changes for macOS Mojave 10.14.4 (18E226) on http://swcdn.apple.com/ also required minor modifications of createInstall.sh for Mojave 10.14.4 (18E2034), which else also still reveals receptive Install macOS Mojave.app version 14.4.10. Corresponding Update of Section D.2) completed. New versions of createInstaller-10.14.4-23042019.sh.zip and createInstaller-10.14.4-SB-23042019.sh have been linked in the guide in the originating post of this thread. Enjoy and have fun, Edit: Update of createInstaller-10.14.4-SB-23042019.sh as I accidentally renamed and linked old file before.
  2. New createInstaller.sh scripts for macOS Mojave 10.14.4 (18E226) and macOS Mojave 10.14.4 (18E2034) - special buildApple recently changed the index for macOS Mojave 10.14.4 (18E226) on http://swcdn.apple.com/, although resulting Install macOS Mojave.app version remains 14.4.08. I therefore expect the respective macOS Mojave 10.14.4 build still to be 18E226.Respective changes for macOS Mojave 10.14.4 (18E226) on http://swcdn.apple.com/ also required minor modifications of createInstall.sh for Mojave 10.14.4 (18E2034), which else also still reveals receptive Install macOS Mojave.app version 14.4.10. Corresponding Update of Section D.2) completed. New versions of createInstaller-10.14.4-23042019.sh.zip and createInstaller-10.14.4-SB-23042019.sh have been linked in the guide in the originating post of this thread. Enjoy and have fun, Edit: Update of createInstaller-10.14.4-SB-23042019.sh as I accidentally renamed and linked old file before.
  3. Well if you ever want to use any: https://github.com/KGP/X299-System-SSDTs/tree/master/ASUS WS X299 Sage 10G But in this case you should also add additional ACPI replacements implemented in the config.plist of my EFI-Folder distribution: https://github.com/KGP/X299-EFI-Folder-Distributions
  4. Yea.. that's what I said, I should remove everything and properly replug the motherboard, which however is a major endeavour because of my custom water blocking Great that you removed all USB3.1 issues Interesting.. I never tried to boot without any TSC kext with this motherboard. I will see what happens in my case. Are you using SSDT for NVMe in PCIEx card adapter?
  5. @fabiosun, just found the source for the problem of irresponsive Windows and macOS functionality, which was not at all related with populating the 3rd EATX onbaord connector but related with a BIOS feature I changed in parallel. Apparently, with Above 4G enabled, Frist VGA 4G Decode must be set to Auto, as else with Frist VGA 4G Decode set to Above 4G, Windows and macOS behave irresponsive after system boot.
  6. BTW.. there is another Boost of approx. 6000 in Skylake-X Geekbench scores either related with 10.14.5 Public Betas or recent modifications within the latest Geekbench software distribution.
  7. Maybe some other PCIe slot I did not populate but you did is using PCIe lanes assigned to the two USB 3.1 back panel connectors? I don't think that the two USB 3.1 back panel connectors are using PCH lanes assigned to Slot-2, when using any x4 TB adapter in this latter slot. I would be also surprised if the else quite sophisticated PCIe/PCH lane management of the Sage would have conflicting lanes assigned twice to two respective devices. My problem is now how to get the silver contact plate actually blocking my USB3.1 Type-A connector in its place without removing everything incl. water blocking
  8. That's weird and does not happen in my case. Just checked on that. SD1-T0500D is external Dell 500 MB Tunderbolt3 NVMe and Trident is USB 3.1 Type-C. All 4 back panel USB3.0 ports are working too. Just realised that I mounted the motherboard such that one of the silver contact plates for the USB3.1 Type-A connector accidentally blocks the latter, thus I cannot test it at present, but I am sure it would work too.
  9. I have TTR in slot-2 from above as recommended by ASUS for the X299 Sage. As far I know, TB adapters just work in this slot assigned to PCH lanes. Also in BIOS TB settings it is the only option available. In slot-1, I use now a EK water blocked VII without problems, in slot-3, I have my OSX WIFI and in slot-5, I use a water blocked NVMe PCIe adapter for my EVO 970 Pro.
  10. Yea.. was using a simple PCIEX cable too. Will further investigate the problems I faced with it. Thanks for your answer and happy holidays to you too!
  11. @FabioSan, I tried now to also use 3rd EATX connector as you recommended, but my system gets irresponsive after system boot and login under Windows and macOS with such configuration.
  12. Because connecting the 2x 8pin EATX connectors at the top to me seemed sufficient for usual OC purposes and because up to know I thought that one would need to connect the 3rd EATX connector only in case of special and extreme overclocking. Did you make any different experience and observation on that? Certainly not a big deal to also connect the 3rd EATX connector if it would be really beneficial for the allover system performance. Please let me know about your appreciated opinion.
  13. Radeon VII now considered within Whatevergreen Source Code distribution I just asked @VIT9696 to consider all necessary Radeon VII details within his Whatevergreen Source Code distribution and he kindly did immediately. Radeon VII is now also part of WEG and all necessary cosmetics are now also properly displayed under "About this Mac" and "Graphics/Displays" of Apple's system report also by means of WEG and not only as up to now by means of my SSDT-X299-Radeon-VII.aml available in my Github SSDT repositories. For respective testing purposes, I removed my respective Radeon VII SSDT temporarily. The new version of WEG however seems to work also well in line with the actual version of my SSDT-X299-Radeon-VII.aml and the Kozlek/Interferenc FakeSMC/HWSensor kext distribution that I recently modified to properly display Radeon VII GPU Temps under iStatMenus and which is also hardwired such within my 10.14.5 EFI-Folder Github distribution. Against former claims of others, the current Radeon VII WEG consideration does not seem to have any effect on respective Geekbench scores either.Let’s see if all the above remains valid after long term testing not only by myself but also by other users, moreover as everything related to the VII should be considered as beta in any case. Enjoy and have fun, Edit: Note that the new WEG source code also seems to fix some actual or at least some former macOS inconsistencies concerning "compatible", "subvendor-ID",... GFX0 and HDAU properties. Thus anybody using my RadeonVII SSDT in addition to WEG, needs to download and implemented the new modified RadeonVII-WEGVII SSDT from my respective Github libraries, after the usual adaptation to motherboard and PCI-Slot Population. I also dropped the formerly implemented load table created with VGTab (version for Vega64) but apparently not fully compatible with Radon VII, as it actually does not seem to provide major improvements and therefore rather would be confusing in the ongoing beta testing. All other above conclusion however seem still valid also after the actual changes in the RadeonVII-WEGVII SSDTs.
  14. Looks rather like some Apple beta driver mess in the frame of the actual VII implementation or some missing update of respective benchmark tools different than Luxmark. I can confirm a drop of 30.000 (200.00 vs 170.000) scores in Geekbench OpenGL and Metal scores with 10.14.5 Beta 2 also in case of my Nitro+ Vega 64. In contrary, Luxmark Scores slightly increased from 28.000 to 33.000. Update: I now also performed a Cinebench OpenGL benchmark for my Nitro+ Vega 64 and surprisingly even there scores slightly increased from 162 fps to 166 fps. Thus in conclusion, seems we are rather missing some Geekbench update and should not blame Apple.
  15. Flawless update to 10.14.5 Beta 2 (18F108f) No further improvements in Radeon VII performance on my X99 system so far (quite identical overall benchmark scores when compared with Beta 1) but H264 and HEVC support.  Enjoy and have fun,
×