Jump to content

Driftwood

Members
  • Posts

    464
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Driftwood

  1. Adobe Apps Patch LINK. As a reminder for the group ALL Adobe BETA products now work without patching EXCEPT Photoshop and Illustrator. These Adobe Creative Cloud (2020) patches will do everything for current releases, but soon you wont need to do all of CC hopefully on final release (lets hope they do'nt recompile the Release candidates!). https://gist.github.com/naveenkrdy/26760ac5135deed6d0bb8902f6ceb6bd
  2. @dtek Aquantia shouldn't need anything. Its supported by Apple. Shouldn't need to add anything for it. The Intel 10G should need a kext I believe, I replaced my wifi pic card like others here to Broadcom Mac compatible.
  3. Big Sur Bare Metal Candle Test (Not as Quick As Proxmox, however we are using a patched dylib library replacing BMDs own to get Davinci Resolve working under Big Sur / AMD bare metal - and AMD BM is not supported under Mac from Davinci.. But even with the patch, it's still very acceptable. * On Proxmox I was getting apx 34fps on 66 Blur Nodes, Here around 20-24fps at moment of screen grab. Had a load of background apps going on if that didn't help. Test is available from here: https://www.liftgammagain.com/forum/index.php?threads/resolve-standard-candle-benchmark.3718/. (top three links in comment 1 of thread) Free Version of Davinci Resolve available here from BMD: https://www.blackmagicdesign.com/uk/support/ (see latest downloads, bottom left hand pane of browser) Davinci Patch For AMD: AMD-Davinci-Fix .zip (from iGPU link)
  4. @iGPU Yeah I saw he had a number of misfortunes. Tragedy. Think it was Macpato on Discord who said he went back to Apple. Who knows, but we miss him.
  5. @dtek Do u have this in BIOS? Or equivalent? I enabled S5 Soft off for USB wakeup and it seems it guarantees it in BS BM. Havent tried the others yet...
  6. Now PikerAlpha is a legend... works for Apple now I heard! Oh, and there you are @fabiosun all over the comments! :-) I used to read his stuff. One of the best gurus around. :-) So we're back to looking for 0x3f Boy! Havent times moved on @fabiosun ?
  7. Either. The methodology is exactly the same. If you set Above 4G on in BIOS, it may (or may not ) have different MMIO values found in your debug file. I think most of us with lots of devices inside our computers have it Enabled (and csm disabled in BIOS) See the blue highlighted bits here highlighted from the OC debut? The hex values are;- e.g.See straight after the text 'MMIO devirt' you'll see the first one - 0xCB100000 So enter this in Hackintools calc (or any hex to dec calculator) and it will give you the decimal value like in the example below (e.g. Hex to decimal value in mine = 3406823424) , then enter that Decimal value into a child under 'mmiowhitelist' in 'Booter' section of Config.plist. Do it for each hex to decimal value on each line (theres 19) from your OpenCore debug .txt and put each decimal equivalent into a new numbered child going up from 0 all the way to 18. You dont need to do 15-18 though as theyre not used. If you leave 15-18 in , make sure their boolean values are set to NO. Here's where the 'Childs' go see 0 the first one and so on... Download a config.plist of ours to see how we did it. But dont copy our values as yours might be different. Just make sure all 0 to 14 are Boolean = YES. For example in this graphic - I'm sure @iGPU exampled all this a few pages back in this thread if you want a clear and concise methodology!
  8. Download Hackintools and use it's calculator or use a hex to decimal converter. Enter each of your hex values and convert to Decimal in this calc, then copy and paste each decimal value into each added child entries which you 'Add' (0 to 18) under mmiowhitelist in config.plist. You find your hex numbers on each line of MMiO section (19 lines of MMIO 0xnnnnnnnnn values) in your opencore debug txt boot log using search. Child 0 to 14 will be Boolean value = Yes. The last four (15 to 18) = No, or you can actually forget about adding the last four child's as they are Negative values (not used)
  9. Did you check your other DP/hdmi port for picture? Sometimes when it goes black, its booted! Maybe upgrade to latest OC build to help too
  10. It's Apple who keep dropping the hardware support. The last great bastion is encoding HEVC PQ Rec2020 420 10-bit for HDR TV/Netflix style delivery. I haven't seen any NLE that can beat x265 CPU encoding. And that's the way I do it and using Handbrake GUI. Threadripper with 32 cores64 threads beats them all at software CPU encodes. Ridiculously fast! At 8-bit HEVC or h264 Media Encoder and fcpx etc... work well. It's 10-bit and now 12-bit HEVC that is the problem as it is so mathematically challenging. Davinci resolve gives me around 8fps in 10 bit. They're all slow outside x265. True 10-bit HEVC hardware support will need to be sorted out in Mac. And Apple are directly responsible for stopping AMD and Nvidia in their tracks - certainly for 'prosumer' level cards. We need encode, not just decode! We wait with baited breath to see support returned.
  11. No its all good. Methinks I don't need any Device Properties I guess. Thanks so much for letting me try. Of course on Air, I don't wanna damage these babies! But I think you gave me a rather safe power table. I get the drift, we're all good in Metal and that's what matters.
  12. @iGPU Gave it a whirl in Catalina: No real performance increase (slight decrease). Im getting 98fps avg on BS without DevProp, but will try it over on BS shortly. Here's OC debug text DevProp rip which I assume success means the DevProps were loaded ok.
  13. @iGPU After trying the DSDT, and looking at comparable builds I am at a losss to explain your 149 fps? There must be something else you are doing or can you get down to the nitty gritty of the DSDT to find out the cause of this graphics performance in CB15? I have to O/c to 4Ghz just to get over 100fps! I really need to understand how. You are not o/c GPU's etc..?. I know u have a decent water block setup but 50% greater than most of us is really quite stunning.
  14. Im definitely getting mediocre results when looking at other TRX40 / Asrock board owners (rocket88). Im going to have to fine tune things...
  15. Thanks @iGPU couldn't see a great deal of difference in BS on benchmark tests. Slight improvement on Apple Compressor rendering! Big Sur BM Tests - NO XMP(Above 4G Enabled, Macpro7,1)
  16. @iGPU Here's the Asrock TRX40 Creator (Above 4G, CSM Disabled BIOS, standard settings) DSDT file to add to your database. Asrock Creator Above 4G no csm DSDT.zip
  17. @iGPU @meina222 Can u rip out all the common essentials for TRX40 and create SSDTs out of them? Be interesting to see.
  18. This sounds like... amazing. Must try it out. What are our common MMIO addresses referencing? Do you know? UPDATE: Like @fabiosun same, an error at start. Hung there and rebooted.
  19. HEVC Encode Test on AMD Threadripper. Adobe Media Encoder Metal Works on AMD Hackintosh - Apple's Compressor doesn't seem to be able to use Metal with AMD Hackintosh. In 5 minutes, Adobe ME Beta had finished transcoding a 10 minute long 12-bit 4444 UHD video file to a HEVC 420 10-bit mp4, in the same time Apple Compressor had barely started - clearly its not making use of Metal and is Software/CPU only. Handbrake is quicker than Compressor using CPU software encoding doing same file 20% quicker than Compressor. Compressor would have taken over an hour to complete so I stopped it! UPDATE: After much reading it appears the following:- HEVC is hardware-accelerated only in single-pass, 8-bit mode. This is reasonably fast, but not as fast as compressing media into H.264. 10-bit HEVC, which is required for HDR media, is compressed in software – and, that takes forever! If you are going to do any form of HEVC encoding, use ffmpeg or Handbrake GUI because they implemented tried and test, fast and efficient encoders developed over many years, AND they fully implement the use of the hardware where it can.
  20. Ok Ive just done a latest commit build using Pavo's OCBuilder to bring my efi's and kexts etc BANG! up-to-date. Here's the latest Big Sur EFI folder complete for Asrock'ers or anyone who needs to analyze for their board. Driftwood Big Sur Bare Metal EFI - Asrock TRX40 Creator EFI.zip
  21. LOL! Its amazing the trouble we go through and all it is is something simple. I guess certain USB hardware is safe and others not. I use a Editors Keys Mac keyboard and is seen by OSX as Mac and works without problems. I guess PC keyboards may be providing the error.
  22. Latest OC061 Commits Config manuals and differences pdfs. Release version should be tomorrow (Pavo). OC061 Latest Commits manual and Differences.zip
  23. @fabiosun and anyone else who wants to see or use my working EFI folders together with config.plists. If you try, simply edit the Platforminfo UUIDs as usual. Also please check if you receive relinked errors either way (ie your Library/Extensions folder has matching kexts or older kexts in these EFIs match L/E - as you may have to update your kextcache kernel cache properly to get these working. For Proxmox you will need to sort out your MMIO, vm.conf, vfio.conf and bl'cklists. Here's the EFI folders:- Proxmox Catalina Driftwood Proxmox - Catalina EFI FOlder.zip Proxmox Big Sur (last used on beta 2) Driftwood Proxmox - Big Sur EFI Folder.zip Bare Metal Catalina Driftwood Catalina Bare Metal EFI Folder.zip Bare Metal Big Sur (works on beta 6) Driftwood Big Sur Bare Metal EFI Folder.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.