Contribute
Register

Strange behaviour with 8700 Quick Sync w/ GTx 1080 Ti

Status
Not open for further replies.
Joined
Feb 9, 2012
Messages
51
Motherboard
Gigabyte Z370 Gaming 3
CPU
i7-8700
Graphics
RX590
Mac
  1. MacBook Pro
  2. Mac mini
Mobile Phone
  1. Android
  2. iOS
Hi guys, I got everything working on the other thread, Compressor let me choose HEVC 8-bit, MacX reported hardware acceleration support and other bells and whistles and great speed.

However, there are some strange behaviours which I like to know whether they're normal or not.

1. VDADecoderChecker never works, always report err: -12473
2. Compressor won't use QSV to encode HEVC if I am transcoding from anther lossy format, but will use QSV if I encode from ProRes
3. MacX Video Converter Pro just report all hardware as a whole like Intel/nVidia/AMD available, instead of separate checkbox for Intel and nVidia.
4. Sometimes Compressor transcode won't work, the process either finish immediately with an empty file, or rendering takes normal time but the file would have black screen with no sound.

Is that normal behaviour for macOS 10.13.2, FCPX 10.4 and Compressor 4.4?

Thanks a million in advance
 
Last edited:
Okay, done a lot more experiments with many combinations. Here is what I ended up.

What work:
1. Compressor let me use HEVC 8-bit encode, iGPU is being used when encode to h.264 and HEVC according to Intel Power Gadget
2. Quicktime and Finder preview watch HEVC contents do use iGPU according to Intel Power Gadget
3. MacX Video Converter use iGPU when encode to H.264, but not HEVC. Same file using hardware yield about 80% faster than software
4. VTDecodeXPCService and VTEncodeXPCService do load AppleGVAHEVCDecoder and AppleGVAHEVCEncoder respectively, admittedly VCPHEVC also appears, but playing a 4K HEVC video only use 1.5% CPU

What don't work:
1. iTunes crash or black screen when playing paid content either stream or downloaded
2. Final Cut Pro direct output HEVC 8-bit need to be removed and re-added each time in order to be used
3. IOVARenderID and SubID don't appear in ioreg
4. shiki-id don't appear in ioreg
5./Applications/VDADecoderChecker gives err: -12473 (without connected to Gen95 message)

Setup:
1. BIOS IGPU set to enabled, DVMT 64MB pre-allocated and set max to max.
2. Inject Intel, 0x89128086 0x89120003
3. lilu.kext shiki.kext nvidiafixup.kext in EFI/CLOVER/kext/other/
4. boot args: shikigva=60 shiki-id=<Mac-FC02E91DDD3FA6A4> -disablegfxfirmware -v dart=0 kext-dev-mode=1 rootless=0
5. Nvidiaweb option checked, Inject System-ID checked (maybe that shouldn't be there)
6. ACPI patches: HECI to IMEI, GFX0 to IGPU, PEGP to GFX0

I think my problem is that somehow shiki.kext (2.2.0) doesn't load properly, the dead give away is shiki-id doesn't appears in ioreg, and also because I could achieve the same result without shiki.kext and nvidiagraphicsfixup.kext.

Any idea would be much appreciated.

Thanks
macbrush

P.S. My system details
CPU Core i7-8700 UHD 630
MB Gigabyte Aorus Z370 Gaming 3
Gfx Gigabyte GTx 1080 Ti 11GB
macOS 10.13.2 Supplement Update
 

Attachments

  • config.plist
    7.6 KB · Views: 249
  • :Violumes:EFI:CLOVER:Kext:Other.png
    :Violumes:EFI:CLOVER:Kext:Other.png
    10.8 KB · Views: 134
  • :Library:Extensions.png
    :Library:Extensions.png
    69.9 KB · Views: 154
  • ioreg.txt
    136.1 KB · Views: 230
admittedly VCPHEVC also appears

If apps initiate AppleGVA incorrectly, implement VCPHEVC rather than AppleGVAHEVC, rebuild dyld_shared_cache is required, it also reduce UI sluggish in some apps not all, but may cause shiki nv_patch failure (AppleGVA.framework size mismatch after dyld cache updated).

In above condition, patched AppleGVA (unlocked GVA for SKL/KBL + Nvidia) may be required, still need shiki to unlock DRM.

Replace AppleGVA from AppleGVA.framework with attached file, then run below from terminal,

cd /System/Library/PrivateFrameworks/
sudo codesign --deep -fs - AppleGVA.framework
sudo chown -R root:wheel AppleGVA.framework

Reboot without or disable shiki.kext, run below from terminal,
sudo update_dyld_shared_cache -force

Re-enable shiki.kext then Reboot.

Tested with Pentium G4560 + HD610 + GT730 IQSV enabled.
 

Attachments

  • patched 1013x AppleGVA.zip
    931.4 KB · Views: 87
Thanks for all your helps, but unfortunately they didn't work. I even went recompile Lilu, shiki, nvidagraphicsfixup and intelgraphicsfixup from latest source.

Read somewhere that nvidiagraphicsfixup require special board-id or Mac model in order to load, so I tried ngxpatch=vit9696 (supposed to disable board-id check?), but still nothing.

Quest continue...
 
Thanks for all your helps, but unfortunately they didn't work. I even went recompile Lilu, shiki, nvidagraphicsfixup and intelgraphicsfixup from latest source.

Read somewhere that nvidiagraphicsfixup require special board-id or Mac model in order to load, so I tried ngxpatch=vit9696 (supposed to disable board-id check?), but still nothing.

Quest continue...

Have you try boot arg ngfxpatch=pikera (replaces board-id with board-ix).

Patched AppleGVA does not require shiki.kext, VDADecoder has enabled by bin patch and should work, if Nvidia IOVARenderID and SubID exist.
 
Thanks for all the help! I finally (almost) figured it out.

After I moved Lilu.kext and others from EFI/CLOVER to /L/E, I noticed they're not loaded. So I also install lilufriend.kext in L/E/. Not work, but at least now they're loaded according to kextstat. I then played around with shikigva option a bit, and nailed it at 48. Now VDADecoderChecker shown hardware acceleration supported and I no longer need to re-add HEVC 8-bit to FCPX export list.

Only problem is that with shikigva=48, iTunes wouldn't play HDCP content (will stream trailers). I played around with setting a bit more and figured out shikigva=60 will let me play HDCP movie, but will break VDADecoderChecker. I tried 52 and 56 which breaks everything, 12 have similar result as 48 but more consistent, 48 breaks on some boots which I have no idea why.

To be honest, I have rented 1, maybe 2 movies from iTunes in last 3 years. So HDCP isn't a big deal to me at all, and my hack is practically fully functional now. But then since I am so close, I'll probably try to solve it totally, maybe later after the trackday at the coming weekend. There ain't many combinations left for shikigva anyway.

One note though, I couldn't play HDCP on my P2715Q at first, only on U2713HM. I played around with the monitor's setting, and found out that MST need to be set to secondary (probably to prevent the repeater from working).
 
Arhh... I tried patched AppleGVA before I figured out how to get lilu.kext and nvidiagraphicsfixup.kext loaded which obviously didn't (couldn't have) work. I'll try it again tonight see if this can get my hack perfect!

Thanks again!

Have you try boot arg ngfxpatch=pikera (replaces board-id with board-ix).

Patched AppleGVA does not require shiki.kext, VDADecoder has enabled by bin patch and should work, if Nvidia IOVARenderID and SubID exist.
 
Arhh... I tried patched AppleGVA before I figured out how to get lilu.kext and nvidiagraphicsfixup.kext loaded which obviously didn't (couldn't have) work. I'll try it again tonight see if this can get my hack perfect!

Thanks again!

For iTunes DRM issue:

In my case, patched AppleGVA (equal to shikigva=4 ForceCompatibleRenderer) + shikigva=24 (shikigva=8 VDAExecutableWhitelist + shikigva=16 DisableHardwareKeyExchange) everything OK.

Edit: shikigva=48 equal to shikigva=16 (DisableHardwareKeyExchange) + shikigva=32 (ReplaceBoardID), without shikigva=4 VDADecoder work, means that patched AppleGVA has installed successfully.
 
Last edited:
Sounds like 36 might work for me, will post back when I have time to try it.

Thanks

For iTunes DRM issue:

In my case, patched AppleGVA (equal to shikigva=4 ForceCompatibleRenderer) + shikigva=24 (shikigva=8 VDAExecutableWhitelist + shikigva=16 DisableHardwareKeyExchange) everything OK.

Edit: shikigva=48 equal to shikigva=16 (DisableHardwareKeyExchange) + shikigva=32 (ReplaceBoardID), without shikigva=4 VDADecoder work, means that patched AppleGVA has installed successfully.
 
Status
Not open for further replies.
Back
Top