search

acidanthera / bugtracker

Acidanthera Bugtracker
385 stars 45 forks source link

HEVC decoding on AMD GPUs broken in 10.15.2 #613

Closed matteing closed 4 years ago

matteing commented 4 years ago

Hi,

It seems that HEVC isn't quite working in 10.15.2 for AMD GPUs (iGPUless) with the latest WhateverGreen/Shiki. This wasn't occurring previously, and many users are reporting problems since beta.

https://www.insanelymac.com/forum/topic/341063-pre-release-macos-catalina-10152/?page=2 https://www.tonymacx86.com/threads/catalina-10-15-2-update-lost-hevc-h265-acceleration.288563/

cattyhouse commented 4 years ago

Because Apple removed HEVC capabilities from X4000.kext on macOS 10.15.2, that kext applies to RX 4xx / RX 5xx. See /System/Library/Extensions/AMDRadeonX4000.kext/Contents/Info.plist

This happened many times before, HEVC was removed from 10.14, added back to 10.14.5, now removed from 10.15.2, i don't know what Apple is doing.

cattyhouse commented 4 years ago

@vit9696 this dummy kext will add back the HEVC to X4000.kext, wonder if you could make it whatevergreen built-in dummy-hevc-10-15-2.kext.zip

matteing commented 4 years ago

That makes sense. It would also be great if WEG could inject this permanently for the cards, as Apple keeps switching it off at random.

cattyhouse commented 4 years ago

@vit9696 thanks for the patch. just a note, apple disabled HEVC for AMD GPU for some kind of unknown reason.

Earlier this year, I have experienced freeze (gpu.Restart) when looping play HEVC video after adding the dummy kext to force HEVC on RX 560 on macOS 10.14.1-4. The freeze is somehow unknown to 10.15.2 yet, if it happens I will let you know, then it is better to add this as an boot-arg option.

vit9696 commented 4 years ago

It is added conditionally in the code at the moment. It is likely that this time they just disabled it for us unintentionally.

startergo commented 4 years ago

Just tested the latest WEG. It seemed to decode HEVC, but halfway through playback it garbled the screen output and then panicked. I have 2 Cat drives and both performed the same way: `Panic(cpu 14 caller 0xffffff7f91ad2ad5): userspace watchdog timeout: no successful checkins from com.apple.WindowServer in 120 seconds service: com.apple.logd, total successful checkins since load (350 seconds ago): 36, last successful checkin: 0 seconds ago service: com.apple.WindowServer, total successful checkins since load (290 seconds ago): 17, last successful checkin: 120 seconds ago

Backtrace (CPU 14), Frame : Return Address 0xffffffce58e13820 : 0xffffff801113bb1b 0xffffffce58e13870 : 0xffffff80112733e5 0xffffffce58e138b0 : 0xffffff8011264e5e 0xffffffce58e13900 : 0xffffff80110e2a40 0xffffffce58e13920 : 0xffffff801113b207 0xffffffce58e13a20 : 0xffffff801113b5eb 0xffffffce58e13a70 : 0xffffff80118d2575 0xffffffce58e13ae0 : 0xffffff7f91ad2ad5 0xffffffce58e13af0 : 0xffffff7f91ad27e6 0xffffffce58e13b10 : 0xffffff8011866fcb 0xffffffce58e13b60 : 0xffffff8011870083 0xffffffce58e13ca0 : 0xffffff8011222c22 0xffffffce58e13db0 : 0xffffff8011141998 0xffffffce58e13e10 : 0xffffff8011118625 0xffffffce58e13e70 : 0xffffff801112f0d5 0xffffffce58e13f00 : 0xffffff801124b485 0xffffffce58e13fa0 : 0xffffff80110e3226 Kernel Extensions in backtrace: com.apple.driver.watchdog(1.0)[EFAA17B9-A62C-30B7-9602-0BB5282EDDD6]@0xffffff7f91ad1000->0xffffff7f91ad9fff

BSD process name corresponding to current thread: watchdogd Boot args: -v -liludbgall liludump=10 debug=0x144 -no_compat_check -wegtree shikigva=160 shiki-id=Mac-7BA5B2D9E42DDD94

Mac OS version: 19C57

Kernel version: Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 Kernel UUID: C3E7E405-C692-356B-88D3-C30041FD1E72 Kernel slide: 0x0000000010e00000 Kernel text base: 0xffffff8011000000 __HIB text base: 0xffffff8010f00000 System model name: MacPro5,1 (Mac-F221BEC8) System shutdown begun: NO Panic diags file available: YES (0x0)

System uptime in nanoseconds: 370357936978 `

startergo commented 4 years ago

@vit9696 thanks for the patch. just a note, apple disabled HEVC for AMD GPU for some kind of unknown reason.

Earlier this year, I have experienced freeze (gpu.Restart) when looping play HEVC video after adding the dummy kext to force HEVC on RX 560 on macOS 10.14.1-4. The freeze is somehow unknown to 10.15.2 yet, if it happens I will let you know, then it is better to add this as an boot-arg option.

I got the freeze with HEVC playback through FCPX... plus kernel panics halfway with quicktime playback

cattyhouse commented 4 years ago

Here is my test, i can confirm that there is NO FREEZE or PANIC so far:

  1. add boot-args: shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 on top of my iMac19,2 SMBIOS, make sure everything is using AMD GPU. (i use these boot-args just for testing AMD GPU, so that the iGPU is not used during my test)
  2. use QuickTime to record my 4k screen, i did a 4m47s recording
  3. use QuickTime to save as 1080p in HEVC format, it takes less than 4mins to finish the encoding.
  4. during recording and encoding, the CPU usage is around 3%, it is pretty amazing.
  5. play back the recoded 4k video and encoded 1080p HEVC video using QuickTime and mpv (installed via brew install --HEAD mpv), again only 3% CPU usage.
  6. play back jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv using mpv multiple times during screen recording, only 3% CPU usage.

my spec: i5-8400, RX 470, macOS 10.15.2, opencore-version REL-054-2019-12-13

Thank you vit for the integration.

vit9696 commented 4 years ago

Well, question is what do we want here? I expect this to not be a problem if IGPU is used. Technically I can make this optional.

I would say we can make an option to disable this, as it works fine for most people.

cattyhouse commented 4 years ago

Well, question is what do we want here? I expect this to not be a problem if IGPU is used. Technically I can make this optional.

i think it is fine so far, the panic issue that @startergo is having should be related to some other things.

startergo commented 4 years ago

Just got another kernel panic. this time is wake up from sleep. All suggests the WEG:Failure code:: 0xffffffff 0x0000001f

Please IGNORE the below stackshot

================================================================ Date/Time: 2019-12-13 09:09:05 -0500 OS Version: ??? ??? (Build ???) Architecture: x86_64 Report Version: 29

Data Source: Stackshots Shared Cache: 0x796a000 B31F4FBC-A468-316B-ABFB-A104C0AC0C86

Event: Sleep Wake Failure Duration: 0.00s Steps: 1

Boot args: -v -liludbgall liludump=10 debug=0x144 -no_compat_check -wegtree shikigva=160 shiki-id=Mac-7BA5B2D9E42DDD94

Time Awake Since Boot: 110s

Process: swd [380] Architecture: x86_64 Footprint: 516 KB Start time: 2019-12-13 09:09:05 -0500 End time: 2019-12-13 09:09:05 -0500 Num samples: 1 (1)

Thread 0xd4a 1 sample (1) priority 4 (base 4) <thread QoS background (requested background), thread darwinbg, process darwinbg, IO tier 2> 1 start + 1 (libdyld.dylib + 108541) [0x7fff6abb37fd] 1 1 ??? [0x1002bb454] 1 1 ??? [0x1002bb1dd] 1 1 __stack_snapshot_with_config + 10 (libsystem_kernel.dylib + 136138) [0x7fff6ad143ca] 1 1 ??? [0xffffff80002e3206] 1 1 ??? [0xffffff800099acba] 1 1 ??? [0xffffff80008b3bc1] 1 1 ??? [0xffffff8000306467] (running) 1

Binary Images: 0x7fff6ab99000 - 0x7fff6abcefff libdyld.dylib (733.8) <8E2D3DED-0756-37A0-9D55-B9264CA020B4> /usr/lib/system/libdyld.dylib 0x7fff6acf3000 - 0x7fff6ad1ffff libsystem_kernel.dylib (6153.61.1) <90F8650F-D3A9-38B3-BB8C-B5D3686393BC> /usr/lib/system/libsystem_kernel.dylib Model: MacPro5,1, BootROM 144.0.0.0.0, 12 processors, 6-Core Intel Xeon, 3.46 GHz, 128 GB, SMC 1.39f11 Graphics: Radeon RX 480 (Slot 1, GPU 1), Radeon RX 480, spdisplays_pcie_device, 8 GB Graphics: Radeon RX 480 (Slot 1, GPU 2), Radeon RX 480, spdisplays_pcie_device, 8 GB Memory Module: DIMM 1, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 2, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 3, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 4, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 5, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 6, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 7, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Memory Module: DIMM 8, 16 GB, DDR3 ECC, 1333 MHz, 0x0000, - Bluetooth: Version 7.0.2f4, 3 services, 25 devices, 1 incoming serial ports Network Service: Ethernet 1, Ethernet, en0 PCI Card: Radeon RX 480, sppci_displaycontroller, Slot-1 PCI Card: pci1002,aaf0, sppci_audiodevice, Slot-1 PCI Card: Radeon RX 480, sppci_displaycontroller, Slot-1 PCI Card: pci1002,aaf0, sppci_audiodevice, Slot-2@11,0,1 PCI Card: pci1b21,625, sppci_ahci, Slot-4@7,0,0 PCI Card: pci1b21,625, sppci_ahci, Slot-4@6,0,0 PCI Card: pci144d,a808, sppci_nvme, Slot-2@20,0,0 PCI Card: pci144d,a808, sppci_nvme, Slot-2@19,0,0 PCI Card: pci1b21,2142, sppci_usbxhci, Slot-2@16,0,0 PCI Card: pci1b21,2142, sppci_usbxhci, Slot-2@18,0,0 Serial ATA Device: OWC Mercury Electra 6G SSD, 240.06 GB Serial ATA Device: Samsung SSD 840 Series, 120.03 GB Serial ATA Device: HL-DT-ST DVD-RW GH61N Serial ATA Device: WDC WD50EZRX-00MVLB1, 5 TB Serial ATA Device: WDC WD1001FALS-403AA0, 1 TB Serial ATA Device: WDC WD2500AAJS-75M0A0, 250 GB Serial ATA Device: ADATA SU800, 512.11 GB USB Device: USB 3.1 Bus USB Device: USB 3.1 Bus USB Device: USB 2.0 Bus USB Device: USB 2.0 Bus USB Device: Ultra USB 3.0 USB Device: USB2.0 Hub USB Device: USB 2.0 Camera USB Device: USB Bus USB Device: USB Bus USB Device: BRCM2046 Hub USB Device: Bluetooth USB Host Controller USB Device: USB Bus USB Device: USB Bus USB Device: Hub in Apple Pro Keyboard USB Device: Microsoft USB Optical Mouse USB Device: Apple Pro Keyboard USB Device: USB Bus USB Device: USB Bus FireWire Device: built-in_hub, Up to 800 Mb/sec Thunderbolt Bus:

startergo commented 4 years ago

My Catalina install is fresh so chances it is corrupted is minimal to none. I don't have IGPU, only dual Xeons X5690.

startergo commented 4 years ago

Just to update my testing. It looks like the freezes were due to my odd setup. I had an expansion chassis in PCIE port 2 of my backplane logic board with another GPU installed there. Now I removed the GPU from my expansion chassis and the system does not freeze anymore during playback. Will report if I see any issue. Mojave did not have any issues with the same dual GPU setup.

matteing commented 4 years ago

I agree with @vit9696 - I think the best course of action to take is to add an option to disable the HEVC patches if the user encounters a problem.

Choice is always great, and this will help the tiny amount of people that have odd setups.

vit9696 commented 4 years ago

Ok, done

nidstigator commented 4 years ago

I compiled the latest version and I still see CPU usage %100+ when playing HEVC videos and no HEVC support in VideoProc. All previously worked on .1 Hardware: i7-6700K, AMD RX-580, headless iGPU Using shikigva=16 to get TV+/ other Apple DRM to work.

matteing commented 4 years ago

@nidstigator What is your SMBIOS? You may need to pass a board-id.

Try booting with shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 and report back.

edit: afaik looking at the source shikigva 16 with replaceBoardId panics, so try 32 (replaceBoardId alone).

nidstigator commented 4 years ago

My SMBIOS is iMac17,1 Shikigva=80 causes freezes (when attempting to play FP2.x content) but as far as I’ve know @vit9696 says it’s due to bad RX5xx drivers. Will try the 32+ board ID and report back.

matteing commented 4 years ago

My SMBIOS is iMac17,1 Shikigva=80 causes freezes (when attempting to play FP2.x content) but as far as I’ve know @vit9696 says it’s due to bad RX5xx drivers. Will try the 32+ board ID and report back.

Yep, I have the same problem with DRM - as @vit9696 said, Apple broke the driver implementation in 10.15.

The iMacPro board-id should be best for offloading GVA to the GPU, as that model doesn't really have an iGPU.

startergo commented 4 years ago

Shikigva=48: `panic(cpu 4 caller 0xffffff7f9c2ca869): WhateverGreen: shiki @ Hardware DRM decoder cannot be used with custom board or whitelist

Backtrace (CPU 4), Frame : Return Address 0xffffff8e1a66b260 : 0xffffff8019d3bb1b mach_kernel : _handle_debugger_trap + 0x47b 0xffffff8e1a66b2b0 : 0xffffff8019e733e5 mach_kernel : _kdp_i386_trap + 0x155 0xffffff8e1a66b2f0 : 0xffffff8019e64e5e mach_kernel : _kernel_trap + 0x4ee 0xffffff8e1a66b340 : 0xffffff8019ce2a40 mach_kernel : _return_from_trap + 0xe0 0xffffff8e1a66b360 : 0xffffff8019d3b207 mach_kernel : _DebuggerTrapWithState + 0x17 0xffffff8e1a66b460 : 0xffffff8019d3b5eb mach_kernel : _panic_trap_to_debugger + 0x21b 0xffffff8e1a66b4b0 : 0xffffff801a4d24f9 mach_kernel : _panic + 0x61 0xffffff8e1a66b520 : 0xffffff7f9c2ca869 as.vit9696.WhateverGreen : ZN5SHIKI13processKernelER13KernelPatcherP10DeviceInfo + 0x219 0xffffff8e1a66b660 : 0xffffff7f9c2cc691 as.vit9696.WhateverGreen : ZN3WEG13processKernelER13KernelPatcher + 0x9c1 0xffffff8e1a66b770 : 0xffffff7f9c2cf914 as.vit9696.WhateverGreen : ZZN3WEG4initEvENK3$_0clEPvR13KernelPatcher + 0x24 0xffffff8e1a66b7a0 : 0xffffff7f9c2cf8dd as.vit9696.WhateverGreen : __ZZN3WEG4initEvEN3$_08invokeEPvR13KernelPatcher + 0x1d 0xffffff8e1a66b7c0 : 0xffffff7f9c240100 as.vit9696.Lilu : ZN7LiluAPI27processPatcherLoadCallbacksER13KernelPatcher + 0x90 0xffffff8e1a66b860 : 0xffffff7f9c23bead as.vit9696.Lilu : ZN13Configuration11performInitEv + 0xcd 0xffffff8e1a66b8a0 : 0xffffff7f9c23c0b6 as.vit9696.Lilu : ZN13Configuration10policyInitEPKc + 0xa6 0xffffff8e1a66b8e0 : 0xffffff7f9c23c0f3 as.vit9696.Lilu : ZN13Configuration32policyCredCheckLabelUpdateExecveEP5ucredP5vnodez + 0x23 0xffffff8e1a66b900 : 0xffffff801a4bc8cd mach_kernel : _mac_cred_check_label_update_execve + 0x12d 0xffffff8e1a66b990 : 0xffffff801a274921 mach_kernel : _kctl_fill_socketinfo + 0x1361 0xffffff8e1a66bd20 : 0xffffff801a27c1ae mach_kernel : _posix_spawn + 0x3fbe 0xffffff8e1a66bda0 : 0xffffff801a27d342 mach_kernel : ___mac_execve + 0x372 0xffffff8e1a66be40 : 0xffffff801a27d8db mach_kernel : _load_init_program + 0x1db 0xffffff8e1a66beb0 : 0xffffff801a2427cd mach_kernel : _bsdinit_task + 0x6d 0xffffff8e1a66bed0 : 0xffffff801a29be90 mach_kernel : _bsd_ast + 0x3e0 0xffffff8e1a66bf20 : 0xffffff8019d33589 mach_kernel : _ast_taken_user + 0x119 0xffffff8e1a66bf60 : 0xffffff8019ce2a0c mach_kernel : _return_from_trap + 0xac Kernel Extensions in backtrace: as.vit9696.Lilu(1.4.1)[E499BF50-984A-3D6B-9765-2CAFC8AF8835]@0xffffff7f9c22b000->0xffffff7f9c2a9fff as.vit9696.WhateverGreen(1.3.6)[46E92AEC-7E0D-3877-965F-5410E5FCF84C]@0xffffff7f9c2b2000->0xffffff7f9c339fff dependency: as.vit9696.Lilu(1.4.1)[E499BF50-984A-3D6B-9765-2CAFC8AF8835]@0xffffff7f9c22b000 dependency: com.apple.iokit.IOPCIFamily(2.9)[1286D5E5-A6A1-3C44-A244-04C068903DB2]@0xffffff7f9a8f7000

BSD process name corresponding to current thread: init Boot args: -v keepsyms=1 -liludbgall liludump=10 debug=0x144 -no_compat_check -wegtree shikigva=48 shiki-id=Mac-7BA5B2D9E42DDD94

Mac OS version: Not yet set

Kernel version: Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 Kernel UUID: C3E7E405-C692-356B-88D3-C30041FD1E72 Kernel slide: 0x0000000019a00000 Kernel text base: 0xffffff8019c00000 __HIB text base: 0xffffff8019b00000 System model name: MacPro5,1 (Mac-F221BEC8) System shutdown begun: NO Panic diags file available: NO (0xe00002bc)

System uptime in nanoseconds: 11613910265 `

matteing commented 4 years ago

Shikigva=48: `panic(cpu 4 caller 0xffffff7f9c2ca869): WhateverGreen: shiki @ Hardware DRM decoder cannot be used with custom board or whitelist

Make sure to understand what you're passing to Shiki. You can't pass a custom shiki-id while using the shikigva=16 setting.

shikigva works by adding each setting you want, and you're triggering this line.

shikigva=48 means 32+16, where 16 is the UseHwDrmDecoder setting. Simply pass shikigva=32 and a shiki-id and you should be fine.

startergo commented 4 years ago

Shikigva=48: `panic(cpu 4 caller 0xffffff7f9c2ca869): WhateverGreen: shiki @ Hardware DRM decoder cannot be used with custom board or whitelist

Make sure to understand what you're passing to Shiki. You can't pass a custom shiki-id while using the shikigva=16 setting.

shikigva works by adding each setting you want, and you're triggering this line.

shikigva=48 means 32+16, where 16 is the UseHwDrmDecoder setting. Simply pass shikigva=32 and a shiki-id and you should be fine.

Thanks for the explanation. I am just testing all possibilities. So far 32, 96, 224 and 480 I get HEVC decoding and DRM 1.x decoding. I can't get DRM 2.X (Netflix, Amazon and TV+) TV+ gives me red flickering screen (it plays the trailers only)

matteing commented 4 years ago

Yup, seems about right. DRM is broken on Polaris cards for now.

startergo commented 4 years ago

shikigva=16 plays TV+ contents

corint1 commented 4 years ago

this is not a forum for support ... this site is reserved for developers only ... you have been asked not to spam this area anymore ... nobody is interested in your desperate attempts and the results you cannot interpret or understand. .. use forums for support and if you find a real bug post here with arguments .... thank you