Jump to content

[pre-release] macOS Ventura


3,556 posts in this topic

Recommended Posts

2 minutes ago, dehjomz said:

What sort of voodoo? I’m Always interested in what Apple changes…

KernelCollections have no spec, so it was always not easy to guess what their intentions are. It looked like some container format (that had the kernel and in separate segments), but it really is much more of a composite format. When they started doing now was referencing segments that precede the Mach-O header of the inner kernel (i.e., inside a KC segment) in said inner kernel. As we treated the inner Mach-O files as separate, this causes issues (basically a negative offset from the header to reach the preceding segment). Though it's now clear, they are not separate, it is one (weird) composite image.

 

I also found the issue with Lilu. It used a deprecated marker segment over the actual segment for the inner kernel. Supposedly for backwards-compatibility of tools, Apple preserved segments that were used by the old prelinkedkernel to still somewhat work with KernelCollections. This specific marker (__PRELINK_TEXT) now broke. Fixes are queued but untested.

  • Like 10
  • Thanks 5
Link to comment
Share on other sites

1 hour ago, aben said:

New development for Skylake users: 

As tested and observed, currently (as of beta 2) it is possible to achieve iGPU acceleration on SKL with help of KBL kexts/profiles (spoofing) however this came with caveats, as expected; specifically with regards to codec(s) hw-decode support. The first noticeable issue was YouTube-playback on Safari, which was resolved by simply dropping the VP9 flag from the KBL profile, since SKL does not have VP9 hw-decode support. All credits to @dhinakg and @PMheart for their collaborative work implementing a robust patch into WEG while maintaining KBL kexts untouched as possible.

Upon further testing, it seems there is actually one more codec-related issue still lurking; this time with HEVC encoded playback  even though VideoProc/VDADecoderChecker do report "full" acceleration status (enc/dec) for HEVC codec. Those spoofing to KBL may test this out by playing a HEVC encoded video via VLC, QuickTime Player etc. you should see garbled/half green frames.

After performing a few tests over the past week, I was able to track down the problematic HEVC flag in KBL profile that causes this incompatibility with HEVC playback on SKL and managed to implement a working patch in a test branch of WEG that fixes this issue. I must admit the code implemented is not exactly perfect but it does the job as far as my testing goes; no more HEVC codec issues seen.

 

SKL users on Ventura may choose to test below attached WEG 1.6.1 SOLELY for testing HEVC related issues or as a temporary solution while waiting for official support from Acidanthera members. CC @PMheart

skl-hevc-test.zip 400.95 kB · 5 downloads

Green screen is indeed a problem which I heard from users, while I have no idea...

 

But now thanks! Where may I find your patch?

  • Like 1
Link to comment
Share on other sites

11 hours ago, eSaF said:

Hi - can you post your config.plist after removing your personal data so that I can make a comparison to my own because even though I use the above command script, I am not getting the same results as you. Thanks.

Good morning. 

This is what I have in deviceProperties related to the Intel 630. Nothing related to the AMD (really I have agdpmod=pikera needed for my 6600 but not for your 580). iMac19,1 SMBIOS. iGPU enabled (not Auto) in BIOS.

 

Spoiler

config.thumb.png.0c53b0bcaa03bca87caa0435564a727d.png

 

After running defaults write com.apple.ActivityMonitor ShowGPUTab -bool true both GPU are in the new GPU tab and both are built-in.

 

Spoiler

built-in.png.eb03d9125daa3fda5695213b94b29a1b.png

 

Show me your current config.plist.

 

  • Like 1
Link to comment
Share on other sites

For me releases of OC 0.8.* Big Sur and Monterey iterations have always worked extremely well when used in conjunction with recent Intel platforms for which Apple has not dropped support, ie Haswell, Skylake as well as Comet Lake based platforms.

 

Older hardware is not in use in my environment therefore I am not qualified to pass judgment on that.

 

At this stage Ventura is however a completely different kettle of fish. I treat Ventura as I would treat a newly born infant in a maternity ward, placing all my trust into the qualified staff of that institution to do everything possible to ensure that that infant will eventually grow and mature into a healthy human being.

 

Without any qualification, I also afford that same trust to the developers of OC knowing, that with time and dedication, as well  as patience on our part, success will finally be achieved for the benefit of all OC users, also knowing that the "baby" called "Ventura" may or may not still undergo considerable "personality changes" whilst growing and maturing. 

 

Just my 2 cents worth.

 

Greetings Henties

 

 

 

Edited by Henties
  • Like 4
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

Thank you for your wonderful development.

 

The kernel prelink problem seems to be difficult.


I waited a bit and then felt like applying DB3.


My Fliseserver has an SSD image of DB2 so it's easy to write it back.


I would like to test it if I get any notice.

 

I look forward to working with you.

 

Thank you.

Link to comment
Share on other sites

21 minutes ago, miliuco said:

Show me your current config.plist.

Sure thing Bro - See attached, actually I managed to change mine thanks to @5T33Z0 for the GPU Tab script,  @FirstTimeCustomac for posting his example, so mine now says both are Built-in, but I discovered I can also make UHD 630 Built-in and the RX580 in a designated Slot but settled for both to be Built-in as stated to be the correct configuration by some.

Spoiler

1945689238_Screenshot2022-07-07at12_16_18.png.55b1b7ee8e98285c0f80a5f7a7b97530.png686430047_Screenshot2022-07-07at12_15_58.png.bff9c543d6c1c699ac5b04bbe14e7c3f.png

 

config.plist

  • Like 5
Link to comment
Share on other sites

Guest 5T33Z0

@eSaF How did you make the GPU appear to be "Internal"? Side-note:  framebuffer-patch-enable is only required when driving a display, not when using an empty framebuffer.

Link to comment
Share on other sites

9 minutes ago, 5T33Z0 said:

@eSaF How did you make the GPU appear to be "Internal"? Side-note:  framebuffer-patch-enable is only required when driving a display, not when using an empty framebuffer.

I don't really know man, I just blindly followed @FirstTimeCustomac posted example and picked out what I thought was relevant to my own (right or wrong) and hoped for the best :). All the info is above.

Link to comment
Share on other sites

2 hours ago, PMheart said:

Green screen is indeed a problem which I heard from users, while I have no idea...

 

But now thanks! Where may I find your patch?


Not exactly the implementation I was aiming for code-wise. Exhausted all possible attempts to try and drop just the relevant value from the array object without having to drop the entire property, even tried referencing and applying other patching approaches implemented across WEG but all workflows failed. For someone with limited proficiency in C++ this is expected, hence did not bother submitting a PR as well; to Acidanthera my attempts will probably look laughable 😅

Edited by aben
Link to comment
Share on other sites

Guest ricoc90
2 hours ago, 5T33Z0 said:

@eSaF How did you make the GPU appear to be "Internal"? Side-note:  framebuffer-patch-enable is only required when driving a display, not when using an empty framebuffer.


Remove AAPL,slot-name from both the iGPU and dGPU.
iGPU properties:
DP.png.21a45def62a6ba37a560840476151f3b.png

device-id is just cosmetic (to have it show up as uhd 630 rather than "KBL Unknown" and platform-id is a non-headless framebuffer to allow GPU history to actually monitor the iGPU usage (both thanks to @FirstTimeCustomac)

dGPU properties:
image.png.2a382223859304e2ff9c58ad1577e432.png

Edited by ricoc90
Link to comment
Share on other sites

19 minutes ago, aben said:


Here you go: https://github.com/abenraj/WhateverGreen/tree/SKL-HEVC-test

 

Not exactly the implementation I was aiming for code-wise. Exhausted all possible attempts to try and drop just the relevant value from the array object without having to drop the entire property, even tried referencing and applying other patching approaches implemented across WEG but all workflows failed. For someone with limited proficiency in C++ this is expected, hence did not bother submitting a PR as well; to Acidanthera my attempts will probably look laughable 😅

I saw it myself hours ago, thanks anyway. :) 

 

Do we need to remove IOGVAHEVCDecodeCapabilities? Is it confirmed to work?

 

And I saw another branch where it failed, but you removed it I guess? What were you attempting to do there? I could help write the correct code.

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly?

 

15 minutes ago, antuneddu said:

Done !!! 

1242753808_Screenshot2022-07-07alle14_03

If necessary, download the update again ... thanks Devs 💪

Lilu-1.6.1-RELEASE.zip 772.47 kB · 6 downloads OpenCore-0.8.3-RELEASE.zip 5.57 MB · 5 downloads

While I do not like the idea of redistribution (again), please at least state from which commits the files are...

Edited by PMheart
Link to comment
Share on other sites

15 minutes ago, PMheart said:

I saw it myself hours ago, thanks anyway. :) 

 

Do we need to remove IOGVAHEVCDecodeCapabilities? Is it confirmed to work?

 

And I saw another branch where it failed, but you removed it I guess? What were you attempting to do there? I could help write the correct code.

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly?

 

While I do not like the idea of redistribution (again), please at least state from which commits the files are...

I'm sorry if it's not so I thought I was doing a good thing by redistributing, I wanted to facilitate others

 

https://github.com/acidanthera/OpenCorePkg/commit/f3cd35a957bb9c73aa0b1807fb2fde553296389f OC 

 

https://github.com/acidanthera/Lilu/commit/9008be3761602282a542a32b68716b2b86bdb1a1  Lilu

 

  • Like 8
Link to comment
Share on other sites

13 minutes ago, PMheart said:

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly? 


You are indeed correct :) More specifically I was aiming to drop the value "2" under "VTSupportedProfileArray" (most likely a reference to profile 2 that's not present on SKL kexts). Just dropping this value fixes the playback issue.

Link to comment
Share on other sites

10 minutes ago, aben said:


You are indeed correct :) More specifically I was aiming to drop the value "2" under "VTSupportedProfileArray" (most likely a reference to profile 2 that's not present on SKL kexts). Just dropping this value fixes the playback issue.

Thanks for letting me know; I will handle it.

  • Like 5
Link to comment
Share on other sites

Finally!!! installed on my little Alder Lake 

 

705405461_Capturadepantalla2022-07-07alas14_48_03.thumb.png.c701109cf8bd8db6879d6e96431693eb.png

 

:drool:

 

Now I have it installed on Lenovo 520s, it seems that everything is going well at the moment

 

Thank you very much to all of you who make this possible 🙇‍♂️

 

 

  • Like 7
Link to comment
Share on other sites

2 hours ago, Download-Fritz said:

KernelCollections have no spec, so it was always not easy to guess what their intentions are. It looked like some container format (that had the kernel and in separate segments), but it really is much more of a composite format. When they started doing now was referencing segments that precede the Mach-O header of the inner kernel (i.e., inside a KC segment) in said inner kernel. As we treated the inner Mach-O files as separate, this causes issues (basically a negative offset from the header to reach the preceding segment). Though it's now clear, they are not separate, it is one (weird) composite image.

 

I also found the issue with Lilu. It used a deprecated marker segment over the actual segment for the inner kernel. Supposedly for backwards-compatibility of tools, Apple preserved segments that were used by the old prelinkedkernel to still somewhat work with KernelCollections. This specific marker (__PRELINK_TEXT) now broke. Fixes are queued but untested.

Excellent points, thank you for the insight and analysis.  And yes, macOS isn't documented, especially at the start of kernel loading.  So kudos to the OC developers for documenting the undocumented and beginning development on a fix. 

 

Also, Apple added a new lockdown mode to Ventura, I wonder how or if that affects things?  Thank you so much for responding to me.

Edited by dehjomz
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

@eSaF

I wold change in your config.plist:

  • AAPL,ig-platform-id from 0300983E to 0300913E
  • device-id ok (device_type and model not needed, included in device-id)
  • framebuffer-patch-enable removed (not needed on headless mode)
  • enable-metal and igfxfw ok
  • added igfxonln=01000000
  • RX580 code not needed, only if you like to see it in System Profiler >> PCI devices list.

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

25 minutes ago, aben said:

Auto-sleep is back with Beta 3

Yes,  works fine!! :w00t: 

 

lenovo 520s works too

 

1554265789_Capturadepantalla2022-07-07alas15_31_52.thumb.png.8c5b0f6019945f6b33c1de722995f949.png

 

@eSaF

 

the laptop gives me the iGPU as integrated 

 

653057833_Capturadepantalla2022-07-07alas15_36_25.png.a023a6e5ca8494adc0114ca1fbfcdc26.png

Edited by PoMpIs
  • Like 6
Link to comment
Share on other sites

For the first time, my iHack has decided to give me grief. Ventura B3 install fails with the following message: "No port micro restart (we don't support SMC on this platform)". Then it gracefully shuts down all processes and restarts the system. Using OC 0.8.3, Lilu, VirtualSMC and SMCProcessor (unrelated: AppleALC, IntelMausi, WhateverGreen) kexts, all loaded from yesterday's (July 6 2022) build. Monterey boots just fine. Ventura B1 install boots just fine (using it to type this).

 

Guess I'll wait a little longer before I attempt to recover my iHackPro Skylake based...

 

Also, page 69. Noice! 🤣

Edited by Alex HQuest
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...