Leaderboard

Last updated: 15 Jun 2024 We still get recurring questions about some well-known and older unsupported GPUs and graphics cards, so let's try and make a quick recap here. The list can be completed as required and necessary. The list will only apply to SL 10.6 and beyond, not before. Intel ----- Gen3 ----- GMA 900: unsupported since SL. GMA 950: supported in SL and Lion in 32bit kernel mode only; unsupported since ML. GMA 3100/3150: unsupported. ----- ----- Gen4 ----- GMA 3000/X3000: unsupported GMA X3100: supported in SL and Lion in 32bit kernel mode only; unsupported since ML. GMA 4500/4500M/4500MHD/4700MHD: unsupported. ----- ----- Gen5 ----- GMA HD/GMA 5700MHD/1st gen Intel HD (i.e. Ironlake of Clarkdale & Arrandale CPUs): partially (CI (i.e. screen resolution) only) or fully (full QE/CI) supported on laptops from SL 10.6.4 to High Sierra depending on built-in LCD connector (LVDS=full support, eDP=partial support); unsupported since Mojave. Refer to bible thread on the matter. Partial graphics support usually means platform is more or less unusable and therefore unsuitable as a Hackintosh. Special patches required for OpenGL-only support in Mojave and Catalina (and later?). ----- ----- Gen6 ----- Sandy Bridge Intel HD (GT1): unsupported. Sandy Bridge Intel HD 2000 (GT1): unsupported. Sandy Bridge Intel HD 3000 (GT2): supported from SL to High Sierra; unsupported since Mojave. Special patches required for OpenGL-only support in Mojave and Catalina (works very poorly in Big Sur/Monterey so best avoided). ----- ----- Gen7 ----- Ivy Bridge Intel HD (GT1): unsupported. Ivy Bridge Intel HD 2500 (GT1): unsupported; some unconfirmed reports of apparent support in ML from 10.8.3 and partial support (CI only) in El Capitan. Ivy Bridge Intel HD 4000 (GT2): supported from Lion to Big Sur; unsupported since Monterey but patch exists (see footnote). Bay Trail Intel HD (GT1): unsupported. Haswell Intel HD (GT1): unsupported. Haswell Intel HD 4x00/5000/Iris 5x00 (GT2/GT3): supported from ML 10.8.5 to Monterey. Unsupported since Ventura but patch exists (see footnote). ----- ----- Gen8 ----- Cherry Trail Intel HD/HD 4xx (GT1): unsupported. Braswell Intel HD/HD 4xx (GT1): unsupported. Broadwell Intel HD (GT1): unsupported. Broadwell Intel HD 5x00/6000/Iris 6x00 (GT2/GT3): supported from Yosemite 10.10.3 to Monterey. Unsupported since Ventura but patch exists (see footnote). ----- ----- Gen9 ----- Apollo Lake Intel HD 5xx (GT1): unsupported. Skylake Intel HD 510 (GT1): unsupported. Skylake Intel HD 515/520/530/Iris 5x0 (GT2/GT3/GT4): supported from El Capitan 10.11.4 to Monterey. Unsupported since Ventura but patch exists (see footnote). ----- ----- Gen9.5 ----- Kaby Lake Intel HD 610 (GT1): unsupported. Kaby Lake Intel HD 615/620/630/Iris+ 6x0 (GT2/GT3): supported from Sierra 10.12.6 to Sequoia. Kaby Lake R Intel UHD 620 (GT2): supported as per Kaby Lake with KBL framebuffer 0x59160000 and faking KBL iGPU id 0x5916. 8th gen Amber Lake Y Intel UHD 617 (GT2): supported from Mojave 10.14.1 to Sequoia (with KBL settings). ----- Coffee Lake Intel UHD 610 (GT1): unsupported. Coffee Lake Intel UHD 630/Iris+ 6x5 (GT2/GT3): basic support in High Sierra 10.13.6 from 1st Security Update build 17G2208 (iGPU ids 0x3E92/0x3E9B/0x3EA5); extended support from Mojave to Sequoia. Coffee Lake R Intel UHD 610 (GT1): unsupported. Coffee Lake R Intel UHD 630/Iris+ 6x5 (GT2/GT3): supported as per Coffee Lake with faking CFL id 0x3E92 up to Mojave 10.14.3; natively supported from Mojave 10.14.4 to Sequoia. Whiskey Lake Intel UHD 610 (GT1): unsupported. Whiskey Lake Intel UHD 620 (GT2): supported as per Coffee Lake with CFL framebuffer and faking CFL id 0x3EA5. Comet Lake/Comet Lake R Intel UHD Graphics for 10th gen. processor (GT1/GT2): supported from Catalina 10.15.4 to Sequoia with CFL settings. Caution must be exercised though given that Intel somehow recycled Coffee Lake UHD6x0 (itself a refresh of Kaby Lake R graphics). for desktop CPUs, Intel reused the UHD6x0 naming convention: Comet Lake UHD 610 (GT1): unsupported Comet Lake UHD 630 (GT2) supported as per Coffee Lake things differ quite a lot for mobile CPUs: generally speaking, UHD Graphics of mobile Comet Lake i3/i5/i7/i9 "U" CPUs is equivalent to UHD 620 (GT2); those have 23 (i3) to 24xEUs (i5/i7/i9) and are expected to be supported (not necessarily OOB). generally speaking, UHD Graphics of mobile Comet Lake i3/i5/i7/i9 "H" CPUs is equivalent to UHD 630 (GT2); those have 23 (i3) to 24xEUs (i5/i7/i9) and are expected to be supported (not necessarily OOB). as an exception to those rules, some mobile "U" and/or "H" CPUs (eg: i5-10200H) have an iGPU with 12xEUs only which is equivalent to UHD 610 (GT1) -> unsupported. all mobile Celeron and Pentium have a 12xEUs UHD Graphics, i.e. equivalent to UHD 610 (GT1) -> unsupported. known ids of CML iGPU with 12xEUs only: 0x9B21, 0x9BAA, 0x9BA4, 0x9BAC (+ desktop id 0x9BA8) -> unsupported. known ids of CML iGPU ids with 23 to 24xEUs: 0x9B41, 0x9BC4, 0x9BCA, 0x9BCC (+ desktop ids 0x9BC5, 0x9BC8) -> expected to be supported (not necessarily OOB). a recap of CML iGPUs is available in the following Intel document: Intel UHD Graphics Open Source. Programmer's Reference Manual.pdf.zip ----- ----- Note about GT1 iGPUs ----- Basically, from Gen6 HD 3000 to Gen9.5 UHD 6xx iGPUs, there is no support for low-end/entry-level GT1-based Intel HD/UHD graphics. ----- ----- Gen11 ----- Ice Lake Intel UHD (G1): apparently supported from Catalina 10.15.4 to Monterey by faking id of G4/G7 counterparts as stated here. Ice Lake Intel Iris Plus (G4/G7): supported from Catalina 10.15.4 to Sequoia. ----- ----- Later generations (Gen12 and beyond) ----- No support for subsequent iGPU generations to be expected, Apple having switched to M1 silicon after Ice Lake generation. Lots of iGPU info available here: https://en.wikipedia.org/wiki/Intel_Graphics_Technology nVidia GeForce 6x00 and similar (Curie NV4x): unsupported since SL 10.6.3 at least (some cards supported in early SL versions only). GeForce 7x00 and similar (Curie G7x): supported in SL and Lion in 32bit mode only; unsupported since ML. Tesla generation (G8x, G9x, GT2xx) supported SL -> High Sierra; unsupported since Mojave. Special patches required for OpenGL-only support in Mojave and later (see footnote). Fermi generation (GFxxx): supported Lion -> El Capitan; buggy/poorly supported in Sierra and High Sierra; unsupported since Mojave. Kepler generation (GKxxx): supported from Lion 10.7.5/ML 10.8.2 to Big Sur but cards based on GK106 chip are best avoided (driver memory leak issue); unsupported since Monterey, special patches required for Monterey and later (see footnote). Maxwell generation (GMxxx): supported from (late) Yosemite to High Sierra and only with the nVidia Web Driver; unsupported since Mojave (no Web Driver). Pascal generation (GPxxx): supported from (late) Sierra to High Sierra and with the nVidia Web Driver; unsupported since Mojave (no Web Driver). Turing generation (TUxxx) and later: unsupported. Support for Kepler cards was dropped in Monterey beta7, marking the end of official support for the last nVidia cards (i.e. Kepler) that remained usable/supported in macOS until then. Special patches apply thereafter (see footnote). ATI/AMD Radeon X300/X600/X700: unsupported. Radeon X800: apparently supported in SL and Lion; unsupported since ML. Radeon X1000: X1300/X1400/X15x0: supported up to SL; limited support (CI only) in Lion; unsupported since ML. X1600/X1900: supported in SL and Lion; unsupported since ML. ----- Radeon HD 2xxx: some models supported in SL up to High Sierra; unsupported since Mojave. Radeon HD 3xxx: some models supported in SL up to High Sierra; unsupported since Mojave. Radeon HD 4xxx: some models supported in SL up to High Sierra; unsupported since Mojave. Radeon HD 5xxx: many models supported in SL up to High Sierra; unsupported since Mojave. Radeon HD 6xxx: many models supported in SL up to High Sierra; unsupported since Mojave. Radeon HD 7xxx: many models supported from ML to Monterey; unsupported since Ventura. Radeon HD 8xxx: many models supported from ML to Monterey; unsupported since Ventura. ----- R7/R9: many models supported from Yosemite to Monterey; unsupported since Ventura. Polaris 10: Lexa unsupported. Baffin supported from Sierra to Sequoia. Ellesmere supported from Sierra to Sequoia. Careful with Radeon RX550 which exists in both Lexa and Baffin versions (needs to be 640SP and id 1002:67FF). Polaris 20/30: most models supported from Sierra to Sequoia. Vega 10: many models supported from High Sierra to Sequoia. Vega 20: some models supported from Mojave to Sequoia. Navi 10: many models supported from Catalina to Sequoia. Navi 20: unsupported. Navi 21: some models supported from Big Sur to Sequoia. Vavi 22: unsupported. Navi 23: some models supported from Monterey to Sequoia. Navi 24: unsupported. Navi 3x: unsupported. ----- APUs: unsupported. ----- Mojave and later require GCN1.0 cards minimum (i.e. HD 7000/HD 8000/ R7/ R9 Series). An excellent recap of things is available at Dortania's GPU buyer's guide (defunct one here). Not to be missed for detailed guidance on Intel graphics configuration: the WhatEverGreen user manual. An absolute must with complete documentation for Intel iGPUs. NB: Obsolete GPUs for which Apple dropped official support after Lion 10.7.5 (e.g.: GMA950/X3100, GeForce 7x00, ATI X1600) can be supported in ML with MLPF hack (essentially, a hack that runs pseudo ML in 32bit mode with DP1 32/64bit kernel and kexts). Details are available our ML with full QE/CI guides for old unsupported Latitude laptops in our Archives section. The work is based on the original R&D stuff covered in ML on unsupported Macs available at MacRumors.com. Older Intel and nVidia GPUs for which Apple dropped official support after High Sierra 10.13.6 (e.g.: 1st gen Intel HD, SNB HD3000, nVidia Tesla GPUs) can be supported in Mojave/Catalina in OpenGL-only mode by installing drivers from High Sierra and reverting some frameworks. More details in subsequent post below.. nVidia Tesla GPUs may be supported in OpenGL-only mode in Big Sur and later with OCLP patcher. See dedicated thread about Big Sur on unsupported Macs at MacRumors.com. Intel HD4000 graphics may be supported in Monterey and later with special patches. nVidia Kepler GPus may be supported in Monterey and later with special patches (official support was dropped from beta 7). Haswell, Broadwell and Skylake iGPUs were dropped in Ventura, however: Skylake HD 5x0 graphics are pretty much fully supported by faking KBL iGPU, using KBL framebuffer layouts, using WEG 1.6.1 or later and KBL SMBIOS Haswell and Broadwell graphics may be fully supported after patching with tools such as OCLP 0.5.1 and later.

NB: This is a revival of the article I had initially published at InsanelyMac to answer recurring questions that had been raised in the Opencore thread that lives there. Posted October 2, 2021 The Dortania documentation refers to the DVMT pre-allocated memory or "stolen memory" when they mention "memory reserved for the iGPU". Years ago, @Firewolf described in details the relationship between stolen memory and DVMT pre-allocated memory on his blog: https://www.firewolf.science/2015/04/guide-intel-hd-graphics-5500-on-os-x-yosemite-10-10-3/ There's a more recent thread from him here: https://www.insanelymac.com/forum/topic/345377-surface-pro-patch-the-framebuffer-properly-to-get-rid-of-the-dvmt-assertion-patch/ It can be difficult to understand and differentiate DVMT pre-allocated memory, stolen memory, framebuffer memory, cursor memory, framebuffer size, cursor bytes, etc. And all of these have got nothing to do with VRAM of course... Some of us are familiar with the information provided by @Pike R Alpha many moons ago, the WhateverGreen User Manual or the Hackintool app though none of those clearly define what the various memory instances are. Several years ago, @Rehabman also attempted to explain this and his writings somehow collided with most people's comprehension of things. For instance, when @Pike, WhateverGreen or Hackintool refer to stolenmem and fbmem, @Rehabman spoke of framebuffer memory size and cursor bytes. In the case of the Haswell Azul framebuffer layouts, @Rehabman also spoke of the DVMT pre-alloc requirements when the others speak of stolenmem. Inevitably, this can lead to confusion... Definitions: See wikipedia and Google searches. VRAM = Video RAM. Common definition is that it stores the pixels and other graphics data rendered on a computer screen. DVMT = Dynamic Video Memory Technology. A technology used by Intel to dynamically allocate system memory to use as video memory to handle graphics. DVMT pre-allocated memory is the minimum amount, in multiples of 32MB, that will be allocated to the iGPU for handling graphics. By far and large, manufacturers set this to 32MB by default in BIOS (or certainly used to). Framebuffer = a memory buffer held in RAM and containing a bitmap of a video frame, i.e. all the data related to the pixels of an image to be displayed on screen (eg: colours, resolution, etc.). Stolen memory = basically, this is the same as the DVMT pre-allocated memory. As far as Apple's framebuffer drivers/kexts are concerned: framebuffer size (aka stolenmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout (it may change according to image characteristics), as defined in the driver/kext. cursor bytes (aka fbmem for WhateverGreen*) = the size, in bytes, of a framebuffer layout's overlay used for handling mouse cursor (without modifying the framebuffer's data), as defined in the driver/kext. framebuffer VRAM (aka unifiedmem for WhateverGreen) = the max. amount, in bytes, of VRAM allocated by a framebuffer layout, as defined in the driver/kext (since Haswell and Yosemite, this usually is 1536MB). * As stated above, I believe that Whatevergreen only got it right for Haswell Azul framebuffer layouts with which stolenmem, fbmem and cursormem match their target. Thereafter, I'm of the opinion that WhateverGreen used incorrect names where stolenmem means the actual framebuffer size and fbmem means the actual cursor bytes (size), as stated by @Rehabman. Mac OS X/OS X/macOS graphics framebuffers: Let's start by looking at a few examples as illustrated in the WhateverGreen User Manual. 1) Haswell Azul mobile framebuffer 0x0a260006 (used for HD4200/HD4400/HD4600 iGPUs on laptops): ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 If we look inside the binary code of the Haswell Azul framebuffer kext, we'll find: 0600260A 01030303 00000002 00003001 00006000 00000060 D90A0000 D90A0000 00000000 00000000 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 which translates to: 0600260A -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00000002 -> 32MB stolen mem (framebuffer-stolenmem) // Rehabman's DVMT-prealloc requirement 00003001 -> 19MB FB mem (framebuffer-fbmem) // Rehabman's framebuffer size 00006000 -> 6MB Cursor mem (framebuffer-cursormem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) D90A0000 -> Backlight freq 2777MHz D90A0000 -> Max. backlight freq 2777MHz 00000000 00000000 00000800 02000000 30000000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000 01050900 00040000 87000000 -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP (framebuffer-con1-type), flags 87000000 02040900 00040000 87000000 -> port #3/FB@2: index 02, busid 04, pipe 0900, type 00040000=DP (framebuffer-con2-type), flags 87000000 FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 2) Broadwell BDW mobile framebuffer 0x1626006 (used for HD5300/HD5500/HD5600 iGPUs on laptops): ID: 16260006, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS [1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP [2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000507 - ConnectorDP 00000800 02000000 30020000 01050B00 00040000 07050000 02040B00 00040000 07050000 If we look inside the binary code of the Broadwell BDW framebuffer kext, we'll find: 06002616 01030303 00002002 00005001 00000060 D90A0000 D90A0000 00000000 00000000 00000000 00000800 02000000 30020000 01050B00 00040000 07050000 02040B00 00040000 07050000 FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 00000000 00000000 C8000000 which translates to: 06002616 -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00002002 -> 34MB stolen mem (framebuffer-stolenmem) // Rehabman's framebuffer size 00005001 -> 21MB FB mem (framebuffer-fbmem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) D90A0000 -> Backlight freq 2777MHz D90A0000 -> Max. backlight freq 2777MHz 00000000 00000000 00000000 00000800 02000000 30020000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 30020000 01050B00 00040000 07050000 -> port #2/FB@1: index 01, busid 05, pipe 0B00, type 00040000=DP (framebuffer-con1-type), flags 07050000 02040B00 00040000 07050000 -> port #3/FB@2: index 02, busid 04, pipe 0B00, type 00040000=DP (framebuffer-con2-type), flags 07050000 FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 00000000 00000000 C8000000 3) Skylake SKL mobile framebuffer 0x19160000 (used for HD520/HD530/HD540 iGPU on laptops): ID: 19160000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000090F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 We can't look at the binary code of the Skylake SKL framebuffer because Apple changed the way things are coded inside but it basically translates as follows: 00001619 -> layout id (AAPL,ig-platform-id) 01 -> mobile type (framebuffer-mobile) 03 -> 3 x pipes (framebuffer-pipecount) 03 -> 3 x ports (framebuffer-portcount) 03 -> 3 x memories (framebuffer-memorycount) 00002002 -> 34MB stolen mem (framebuffer-stolenmem) // Rehabman's framebuffer size 00005001 -> 21MB FB mem (framebuffer-fbmem) // Rehabman's cursor bytes 00000060 -> 1536MB VRAM (framebuffer-unifiedmem) 6C050000 -> Backlight freq 1388MHz 6C050000 -> Max. backlight freq 1388MHz 00000800 02000000 98000000 -> port #1/FB@0: index 00, busid 00, pipe 0800, type 02000000=LVDS/eDP (framebuffer-con0-type), flags 98000000 01050900 00040000 87010000 -> port #2/FB@1: index 01, busid 05, pipe 0900, type 00040000=DP (framebuffer-con1-type), flags 87010000 02040a00 00040000 87010000 -> port #3/FB@2: index 02, busid 04, pipe 0a00, type 00040000=DP (framebuffer-con2-type), flags 87010000 With the exception of the Haswell Azul framebuffer, we can see that Broadwell BDW and Skylake SKL framebuffers define framebuffer size (WEG's stolenmem) and cursor bytes (WEG's fbmem) characteristics and no DVMT pre-allocated memory (i.e. proper stolen memory). This extends to Kaby Lake KBL framebuffers and later. In my opinion, it's fair to say that @Rehabman's description and wording are the most appropriate/best ones when the WEG view of things got somehow misled by following through on the Haswell framebuffer decoding. To me, there was some mixup, leading to confusion and the said confusion has remained ever since... Confusion... why? Because of several things: 1) the observation that the Haswell Azul framebuffers used on Hacks (0x0D220003 for desktops and 0x0A260006 for laptops) defined: a DVMT pre-allocated memory (= Stolen memory) size of 32MB a framebuffer size of 19MB a cursor bytes of 0MB (desktops) and 6MB (laptops; required to be increased to 9MB to fix a minor graphics glitch on some systems) 2) the observation that the Broadwell BDW framebuffers used on Hacks (0x16220007 for desktops and 0x16160006 for laptops) defined: no DVMT pre-allocated memory requirement at all framebuffer sizes of 38MB and 34MB respectively cursor bytes of 38MB and 21MB respectively 3) the observation that the sum of framebuffer size + cursor bytes must be lower than the size of the DVMT pre-allocated memory, failing which a KP occurs at graphics initialisation during startup/boot. 4) In the case of the Haswell Azul framebuffers: DVMT pre-allocated memory requirement is set at 32MB framebuffer size + cursor bytes = 19+0 | 19+6 (or 19+9) = 19MB | 25MB (or 28MB) which is lower than DVMT pre-allocated memory 32MB -> All is Ok by default. 5) In the case of the Broadwell BDW framebuffers: framebuffer size + cursor bytes for desktops = 38+38 = 76MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most desktops, unless adjusted in BIOS framebuffer size + cursor bytes for laptops = 34+21 = 55MB which is greater than the usual/default 32MB DVMT pre-allocated memory of most laptops, unless adjusted in BIOS -> Not Ok by default, Kernel Panic (KP) encountered. 6) And the story is the same with subsequent Skylake, Kaby Lake, etc. framebuffers. Solution: 2 x solutions were engineered to address the issue of KP at graphics initialisation. increase the DVMT pre-allocated memory set in BIOS. Could be complicated and tricky for PCs that do not offer this in BIOS Setup but made easy with Grub Shell if DVMT pre-allocated memory can be identified in BIOS. This method is usually required to gain 4K output. patch the Broadwell, Skylake, Kaby Lake, etc. framebuffer layouts to reduce framebuffer size and cursor bytes so that the sum of them totals less than the usual default DVMT pre-allocated memory of 32MB. This solution does not usually support 4K output. Although some people do opt for the 1st solution, most people just adopt the 2nd one. How were the framebuffer patches derived? If we look at the framebuffer patches that are commonly and generally used, we can observe that they set: WEG's framebuffer-stolenmem property , i.e. framebuffer size to 0x01300000 = 19MB (DATA type set to 00003001) WEG's framebuffer-fbmem property, i.e. cursor bytes to 0x00900000 = 9MB (DATA type set to 00009000) i.e. the values typically used on laptops with Haswell iGPUs, this simply because 19+9=28MB which is < 32MB. This is where it all appears to come from. Is this correct? By far and large, it is. But the need to apply such framebuffer patches depends entirely on the host PC's default DVMT pre-allocated memory. On desktop and laptop PCs where DVMT pre-allocated memory can be adjusted in BIOS setup, the patches are unnecessary as long as the DVMT value that is set exceeds the total of the framebuffer size + cursor bytes of the selected/target graphics framebuffer. Typically, a value of 64MB or 96MB takes care of things perfectly, including 4K. Of course, those PCs manufactured with default DVMT pre-allocated memory set to 64MB or more are unlikely to encounter any issue at all. The framebuffer patches are also unnecessary if the default DVMT pre-allocated memory is increased either though BIOS binmod (difficult and risky) or through Grub shell mod (easy and quickly reversible). This is well illustrated on @Firewolf's blog, linked above (there are other places too such as @Jake Lo's FAQ item here). To give an example, on some Dell laptops (eg. Broadwell Latitude E7x50 or Skylake Latitude E7x70), DVMT pre-allocated memory can be increased by booting a Grub shell and entering the following command: setup_var 0x432 0x3 This sets DVMT pre-allocated memory parameter located at offset 0x432 to 96MB (0x1 for 32MB, 0x2 for 64MB, 0x3 for 96MB, etc.), the default setting for the laptop in this example being 32MB. This setting will remain valid/in place until BIOS is reset to default settings. It's required to obtain 4K output out of DP/HDMI. Of course, different computers will have different locations/offsets for DVMT pre-allocated memory. What should I do then? As stated above, the framebuffer patches apply to most if not all cases. But not for 4K output. Those who feel adventurous or who are computing-literate may opt for the BIOS adjustment alternative. In all cases, the 1st thing to do is to look at the default framebuffer size and cursor bytes settings of the targeted graphics framebuffer, then decide if the sum of them both fits or not in 32MB or any other value set in BIOS for DVMT pre-allocated memory. Can I use different values? Absolutely! As long as the golden rule is respected: framebuffer size + cursor bytes < DVMT pre-alloc mem or, in WEG's conventions, stolenmem + fbmem < DVMT pre-alloc mem. To give a practical example, I experimented on my Skylake/HD520 Dell Latitude E7270 Hackintosh laptop: default DVMT pre-allocated memory value set in BIOS: 32MB target SKL framebuffer layout: 0x19160000 default framebuffer size: 34MB default cursor bytes: 21MB sum of framebuffer size + cursor bytes: 55MB (i.e. > 32MB) Booting with default DVMT pre-alloc mem + no framebuffer patches -> KP/freeze Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 12MB -> KP Booting with default DVMT pre-alloc mem + framebuffer size 19MB + cursor bytes 9MB -> Ok, full graphics acceleration, no 4K output Booting with default DVMT pre-alloc mem + framebuffer size 20MB + cursor bytes 10MB -> Ok, full graphics acceleration, no 4K output Booting with DVMT pre-alloc mem set to 64MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output Booting with DVMT pre-alloc mem set to 96MB (Grub shell) + no framebuffer patches -> Ok, full graphics acceleration + 4K output

I get the impression you don't fully understand half of what you're doing/writing. 1) "BIOS patched to max 2048MB" ? Very much doubt you'd need to set DVMT to that much. I don't believe macOS framebuffers will make any use of that. 2) '#' character is used to comment something out in a bootloader's config and boolean values can be expressed as decimal NUMBER or 32bit hexadecimal DATA types (0 is 0 and 1 is 1, no matter the size of the data unit you opt for). You also need to understand that some of those injected properties are purely cosmetic (eg: labels, IO locations, slot names, etc.). 3) Your linked IOReg bears no relevance to the screenshots and OC EFI you posted (it shows Monterey kernel, MBP13,3 SMBIOS and SKL iGPU settings). To top it all, the Dortania display documentation you refer to is incorrect; most likely due to copy/paste errors. For instance, there's no such thing as device id 1b59006 for Intel HD 630 iGPU; trouble is that it is totally misleading and the Dortania folks are not (re)known for acknowledging and acting on requests for documentation adjustments. Looks like you're getting all confused (who wouldn't?). You need to do much further reading on the matter of properties injection and graphics settings. Or maybe it's time to give it a rest... I can suggest these links to begin with: https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units https://github.com/acidanthera/WhateverGreen https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards https://osxlatitude.com/forums/topic/17804-what-are-dvmt-stolenmem-fbmem-cursormem-why-do-we-patch-these-for-broadwell-and-later/ https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17587-how-to-spoof-hd520-to-hd620-in-monterey-in-preparation-for-ventura

Last updated: 15 Jun 2024 Restoring support for dropped GPUs in macOS Big Sur and Monterey Best thing to do is favour OpenCore Legacy Patcher (OCLP) tool against other own made tools that are mostly packaged scripts based on developpers work. 1) Big Sur: macOS 11 officially dropped support for Ivy Bridge but the drivers for HD4000 graphics (i.e. Capri framebuffer kexts) remained provided. As such, Big Sur may be installed on Ivy Bridge/HD4000 Hackintosh computers with the SMBIOS of a Haswell (or later) Mac model, then booted with a regular Ivy Bridge SMBIOS as long as boot arg -no_compat_check is used. for 1st gen Intel HD graphics, apply root patches with OCLP, making sure to disable SIP and select an Arrandale SMBIOS (eg: MBP6,2); no need for any other OCLP settings. for HD3000 graphics, apply root patches with OCLP, making sure to disable SIP and select a Sandy Bridge SMBIOS (eg: MBP8,1); no need for any other OCLP settings. for nVidia Tesla graphics, apply root patches with OCLP, making sure to disable SIP and select the SMBIOS or a Mac Model with nVidia graphics; no need for any other OCLP settings. 2) Monterey: macOS 12 officially dropped support for some (but not all) Haswell platforms and drivers for HD4200/4400/4600 and affiliated (i.e. Azul framebuffer kexts) remained provided. On the other hand, support for Ivy Bridge HD4000 and NVIDIA Kepler was totally dropped with no drivers (i.e. Capri and NVDA/GeForce framebuffers kexts) provided. for 1st gen Intel HD graphics, apply root patches with OCLP, making sure to disable SIP and select an Arrandale SMBIOS (eg: MBP6,2); no need for any other OCLP settings. for HD3000 graphics, apply root patches with OCLP, making sure to disable SIP and select a Sandy Bridge SMBIOS (eg: MBP8,1); no need for any other OCLP settings. for HD4000 graphics, apply root patches with OCLP, making sure to disable SIP and select an Ivy Bridge SMBIOS (eg: MPB10,2); no need for any other OCLP settings. for Haswell/HD4x00 graphics, just make sure to apply MBP11,4 SMBIOS. MBP11,1 or MBA6,2 SMBIOS will no longer apply since these are among the Mac models dropped by Monterey. for nVidia Tesla graphics, apply root patches with OCLP, making sure to disable SIP and select the SMBIOS or a Mac Model with nVidia graphics; no need for any other OCLP settings.

Target macOS release: Ventura 13.x This is a Clover-based installation using the well-known/well documented vanilla method detailed below: Working: full QE/CI with HD520 graphics (with KBL layout 0x59160000, KBL faked id 0x5916, MBP14,1 SMBIOS and Whatevergreen kext v1.6.1 or later) HDMI output OOB but built-in LCD goes off on 1st cable connection. With WEG boot arg igfxonln=1, LCD picture is recovered after closing then re-opening the LID and HDMI is on at 1st boot & after wake mDP output OOB touchscreen with USB HID fix (patch of IOHIDFamily to fake single-user mode) due to Apple dropping support for old USB hardware full audio, including jack microphone input and headset output (with AppleALC kext & layout-id 11) HDMI audio (with KBL con1 connector-type patch) built-in Gigabit Ethernet (with IntelMausiEthernet kext) full CPU power management, including Turbo boost to 3.4GHz (with PlugIn type settings) sleep: Ok through Apple menu->Sleep, lid closure, power button, Fn-Insert and energy savings settings with hibernation mode set to 0 (sleep to RAM) and /var/vm/sleepimage file deleted. wake: Ok through lid opening and power button wireless & bluetooth with any compatible card/USB dongle battery management and monitoring (with ACPIBatteryManager kext) SD card reader (with 1Revenger1's RealtekCardReader kext) integrated webcam OOB keyboard backlight control OOB (for backlit models) audio volume control through Fn-F1/Fn-F2/Fn-F3 brightness control through Fn-F11/Fn-F12 touchpad basic features, incl. buttons (with Rehabman's VoodooPS2Controller kext) but not recognised in PrefPane USB3.0 ports (with Hackintool's generated USBPorts kext) Stage Manager Continuity Camera Not Working: N/A Not tested: SmartCard reader GeekBench v4.4.4 (64bit) gives the following rating: macOS Ventura not natively supporting platforms older than Kaby Lake/HD6x0, it cannot be natively installed and cannot natively run on the Skylake/HD520 Latitude E7270 as used to be the case for earlier versions of the OS. This can however be easily achieved by implementing the following settings which allow keeping a full vanilla installation without calling on add-on patches that would install older kexts, frameworks or other necessary files: use of Kaby Lake framebuffer 0x59160000 (0x591B0000 may also be used but requires further graphics connectors patching) fake Kaby Lake HD620 iGPU id 0x5916 use Kaby Lake platform SMBIOS MacBookPro14,1 use Whatevergreen v1.6.1 minimum to properly support use/fake KBL graphics on Skylake platforms 1) 13.x USB installer creation Using a USB key of 16GB minimum, create a Ventura USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Ventura.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Ventura installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_16GB) The process will take several minutes. Once completed: install Clover bootloader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI Drivers Recommended drivers FSInject SMCHelper Human Interface Devices (optional) Ps2MouseDxe UsbMouseDxe FileSystem Drivers ApfsDriverLoader Memory fix drivers OpenRuntime Additional Drivers (optional) NvmExpressDxe PartitionDxe Themes (optional) BootLoaderChooser (optional) CloverConfigPlistValidator (optional) Install Clover Preference Pane (optional) you must use Clover version r5148 minimum as attached below: Clover_r5148.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip add the (unzipped) HFSPlus driver attached below to the EFI/CLOVER/drivers/UEFI folder HFSPlus.efi.zip open this EFI partition and transfer/copy the files & folders from the Latitude E7270 Ventura Clover pack below to the EFI/CLOVER folder Clover_Pack_E7270_Ventura.zip 2) 13.x installation boot the Ventura USB installer at the Clover main menu, select the "Install macOS Ventura" partition (but don't press [ENTER]) press [SPACE], select -v verbose option in the menu, then choose to boot with the selected options proceed with installation, creating & formatting the target Ventura installation through Disk Utility as/if required on 1st reboot, boot off the USB installer and select the freshly created "macOS install from <target Ventura partition>" repeat this until this partition is no longer offered and only the target Ventura partition is left to boot Reboot the target Ventura partition via your USB installer 3) Post-installation tuning Once the target Ventura partition has booted, complete the 1st boot configuration tuning Once at the desktop, install Clover bootloader on the Ventura partition/disk with the customised settings listed above Once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the Ventura partition/disk Open this EFI partition and transfer the files & folders from the above Latitude E7270 Ventura Clover pack to the EFI/Clover folder You may then reboot and verify that Ventura boots off your disk through Clover Please note that: Clover config of the pack contains HDMI-audio KBL framebuffer patch. Clover config of the pack contains disabled settings for DW1820A wireless card. Enable or remove as appropriate. Booter quirk SyncRuntimePermissions must be removed for Ventura. Edit: 17 Jan 2024 Revised bootpack with modified SSDT-GPRW patched ACPI table to fix intermittent loss of Bluetooth on wake.

This revised version of Clover r5146 restores full stability in Ventura beta1 with AvoidRuntimeDefrag quirk set (failing that systems boot but rapidly freeze). The OpenRuntime Clover module was fixed. Thanks to developper @Jief_Machak for the updated build. Clover_r5146beta-48be65956.pkg.zip This follows findings posted at InsanelyMac stating that older version such as r5137 could boot Ventura without subsequent freeze. Revised pack #3 posted above accordingly. Edit: Fixed lack of HDMI output by changing KBL framebuffer 0x591B0000 to 0x59160000 which has suitable output ports definition. Revised pack #4 posted above accordingly. Not good for HDMI without connector's patching: ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 136 MB, MAX OVERALL: 137 MB (144191488 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 02040A00 00080000 87010000 -> Not good for HDMI output. Needs patching to 01050900 [00080000 87010000]. 03060A00 00040000 87010000 -> Ok for DP, incl audio. Natively good for HDMI: ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI 00000800 02000000 98000000 01050900 00040000 87010000 -> 0105 connector good for HDMI. Type 00080000 required for HDMI audio. 02040A00 00080000 87010000 -> Ok for DP, incl. audio.

'working on my Clover setup and manage to significantly reduce the freezes though not entirely. Sometimes, system still freezes a few seconds after reaching desktop. But it seems to run pretty stable most of the time. Graphics acceleration is acceptable at this stage though not bug free: occasional slow movements on screen and some contents leftovers after closing a window for instance. Or unrecoverable limping system of complete freeze after attempting to watch a Youtube video in Safari. But, hey, what can we expect out of a KBL framebuffer on a Skylake system? Other than than, everything appears to work properly on the E7270: graphics acceleration: Ok with some defects and reduced/degraded performance brightness control: Ok touchscreen: Ok HDMI output: Ok mini-DP output: Ok audio (incl. DP audio): Ok LAN: Ok wireless & Bluetooth (BCM9460CS2): Ok touchPad: Ok USB ports: Ok sleep & wake: Ok SD card reader: Ok Whether this ends up sustainable in the long run for Skylake laptops remains to be seen but you never know... Is it usable for the time being? Clearly not. Edit: Instant wake issue on sleep and HDMI output now sorted. EFI_Clover_r5146_E7270_13.0.b1.zip EFI_Clover_r5146_E7270_13.0.b1_v2.zip EFI_Clover_r5146_E7270_13.0.b1_v3.zip EFI_Clover_r5146_E7270_13.0.b1_v4.zip

As suggested by @aben at IM, I experimented with KBL framebuffer settings on my Skylake/HD520 Latitude E7270. I also updated all add-on kexts to latest versions (Lily & PlugIns) and replaced good old ACPIBatteryManager + FakeSMC by their VirtualSMC equivalent. This allowed me to boot Ventura b1, complete 1st boot setup and reach desktop; the laptop still freezes shortly afterwards so something's still iffy but at least I can boot and with apparent full graphics acceleration: I don't know about older generations but there seems to be hope for Skylake laptops.