Hmn, looking at the wikipedia page
"Intel Iris Pro Graphics are the IGP series introduced in 2013 with some models of Haswell processors ... Since 2016 Intel refers to the technology as Intel Iris Plus Graphics with the release of Kaby Lake."
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 13 Ventura on Unsupported Macs Thread
- Thread starter 0xCUBE
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
"Intel Iris Pro Graphics are the IGP series introduced in 2013 with some models of Haswell processors ... Since 2016 Intel refers to the technology as Intel Iris Plus Graphics with the release of Kaby Lake."
Hello Dandeco, saw your post. I also have a MBP 9,1 and hoping that it will run Ventura in the future as smoothly as Monterey. FYI I am running Parallels Desktop Version 17.1.2 (51548) without a hitch and with latest Windows 10 update switching/accessing files, etc. seamlessly between OSs on the desktop. Much less cumbersome than Boot Camp IMO. Obviously I realize it might not be a cost-effective . cheers
The Iris Pro Graphics (formerly GT3e) is an extended family of integrated graphics processors introduced by Intel in 2012 along with the Haswell microarchitecture.
Families
The following Iris Pro Graphics families exist:- Iris Pro Graphics 5200 (Haswell, 22 nm)
- Iris Pro Graphics 6200 (Broadwell, 14 nm)
Iris Pro Graphics - Intel - WikiChip
en.wikichip.org
They're not sticky. They're just always at the top because they are always the most popular thread.
When I started to scroll down here looking for it, I started to get worried that the thread got pulled for some reason. When I couldn't find it on page two, was becoming very, very worried.
Then went to the Monterey subforum, USM still there. Came back, went super slow, finally found it!!!
As per yesterday’s Changelog of OCLP 0.4.6n, khronokernel has started incorporating Ventura changes into OCLP.
@0xCUBE: Stickies and ‚just started downloading‘ type of messages time and again over the full 12 pages — Why don’t you open a new thread for this superfluous load, where it can stick? It is common practice on serious forums to have a dedicated [DISC]ussion thread in order to keep the main thread effective. Please consider.
We've never done multiple threads, as this has always been more of a discussion thread than a development thread. However if there is something that's of importance then I can sticky it (how do I do that?) I guess. lmk if you have any better alternatives.
I find useless for my MacBook Pro 11,4 discussing if this thread is sticky or not… I am interested in a patch for making Ventura working on it. I will wait patiently.
In an effort to have a look at Ventura running on my 2010 MacPro5,1 w/RX 580, I first tried getting a working install on an SD card using an allegedly natively-supported 2017 27" iMac18,3 w/4.2 GHz i7. After installing to the SD card, the system fails to load however, displaying the can't boot circle with cross graphic and "support.apple.com/mac/startup" text. That was unexpected and disappointing. Back to the drawing board...
Did manage to get it to install on my mid 2014 pro well done to those involved as those said problems with graphics and mouse but at least it runs . What I thought is different is the whole time using Monterey I log in and get the loading screen to desktop yet with Ventura it’s back to normal booting on Apple logo then log in straight to desktop.
Last edited:
I am really looking forward to you super-techy guys getting the loader working for a Mac Pro '13. I am certain the Mac Pro has the power to run Ventura - and I am sure this too will get sorted out. I have Montery running on a MacBook Pro from 2014, and it runs great.
Hello folks,
We would all really appreciate it if you would stop asking questions like "when will patcher be released" or "will there be a patcher?" or "I have XXX will it work on ventura". First of all it is annoying to the people who are working hard on this project. Secondly, as soon as any updates are made, they will be added to the first post in this thread. On top of that, spam posts such as the ones aforementioned fill up the thread, making posts that have actual use hard to find. So please, stop asking about ventura support. We're only in beta 1, and all the information will come to you when it becomes available.
Have a good weekend!
We would all really appreciate it if you would stop asking questions like "when will patcher be released" or "will there be a patcher?" or "I have XXX will it work on ventura". First of all it is annoying to the people who are working hard on this project. Secondly, as soon as any updates are made, they will be added to the first post in this thread. On top of that, spam posts such as the ones aforementioned fill up the thread, making posts that have actual use hard to find. So please, stop asking about ventura support. We're only in beta 1, and all the information will come to you when it becomes available.
Have a good weekend!
New updates to
OCLP: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/998
OCLP: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/998
dyld cache for non-avx is excellent find. But there are also GLDriver bundles for graphics drivers which are present on disk still and use avx2.0 opcodes. if those can't be found in non-avx variant ( or some opcode emulator is used) then this leaves unsupported macs without proper video output ( e.g. macpro 6,1 with rx5500 egpu still won't work)
Thank you OpenCore developers for all your hard work. Take your time. We'll be patiently waiting for the patcher to come.
Last edited by a moderator:
Unfortunately, from what I can tell, it will not be possible to safely/reliably run Ventura on anything pre-Haswell.
Haswell added the lzcnt and tzcnt instructions which, because of how they are encoded, are misinterpreted by older processors as a different instruction instead of failing.
Because lzcnt/tzcnt don't fail on older CPUs, but just do Something Completely Different® (the bsr or bsf instruction respectively), you can't even trap and emulate them. To make matters even worse, bsf often *but not always* gives the same result as tzcnt does (https://stackoverflow.com/questions/43880227/why-does-tzcnt-work-for-my-sandy-bridge-processor). This means that parts of the OS that use tzcnt could appear to superficially work but behave unpredictably.
Apple's x86_64h target does in fact use lzcnt: https://opensource.apple.com/source/xnu/xnu-3789.70.16/osfmk/i386/cpuid.h.auto.html (search CPUID_X86_64_H_FEATURE_SUBSET).
I am baffled by Intel's decision to design lzcnt/tzcnt this way; "you have to check if it's supported before using it, otherwise it will be silently wrong...sometimes" is a horrible design!
The situation for Haswell through Skylake is much better; most of the instructions added in Broadwell through Kaby Lake were never used by macOS (or, in some cases, any major OS). My assessment of each instruction set is below:
Haswell added the lzcnt and tzcnt instructions which, because of how they are encoded, are misinterpreted by older processors as a different instruction instead of failing.
Because lzcnt/tzcnt don't fail on older CPUs, but just do Something Completely Different® (the bsr or bsf instruction respectively), you can't even trap and emulate them. To make matters even worse, bsf often *but not always* gives the same result as tzcnt does (https://stackoverflow.com/questions/43880227/why-does-tzcnt-work-for-my-sandy-bridge-processor). This means that parts of the OS that use tzcnt could appear to superficially work but behave unpredictably.
Apple's x86_64h target does in fact use lzcnt: https://opensource.apple.com/source/xnu/xnu-3789.70.16/osfmk/i386/cpuid.h.auto.html (search CPUID_X86_64_H_FEATURE_SUBSET).
I am baffled by Intel's decision to design lzcnt/tzcnt this way; "you have to check if it's supported before using it, otherwise it will be silently wrong...sometimes" is a horrible design!
The situation for Haswell through Skylake is much better; most of the instructions added in Broadwell through Kaby Lake were never used by macOS (or, in some cases, any major OS). My assessment of each instruction set is below:
Might be a problem at some point:
RDSEED <- Broadwell
ADX <- Broadwell
SMAP <- Broadwell, but kernel mode only
Unlikely but possible to be a problem:
IPT <- Intel Processor Trace; Broadwell; a debugging feature
ACAPMSR <- called arch_capabilities on Linux; Skylake, but kernel mode only; IA32_ARCH_CAPABILITIES MSR
Won't be a problem:
PREFETCHW <- Broadwell, but fails silently on CPUs that don't support it
SMX <- "Safer Mode Extensions" aka Intel Trusted Execution Technology; not used by macOS; I think its absence is actually an artifact of comparing a lower end Haswell laptop CPU and a desktop Kaby Lake CPU; TXT is much older than Kaby Lake.
SGX <- Skylake; removed in newer client CPUs; never used by macOS
HLE <- Broadwell; part of TSX, now disabled by default, support dropped
RTM <- Broadwell; part of TSX, now disabled by default, support dropped
MPX <- Skylake; silently ignored on CPUs that don't support it; support dropped; not included on 10th gen 10nm and some 10th gen 14nm
CLFSOPT <- called clflushopt on Linux; Skylake, but decoded as "rex clflush" on older CPUs which does the same thing without optimizations, so safe
TSXFA <- "TSX force abort", not a real feature; see above
RDSEED <- Broadwell
ADX <- Broadwell
SMAP <- Broadwell, but kernel mode only
Unlikely but possible to be a problem:
IPT <- Intel Processor Trace; Broadwell; a debugging feature
ACAPMSR <- called arch_capabilities on Linux; Skylake, but kernel mode only; IA32_ARCH_CAPABILITIES MSR
Won't be a problem:
PREFETCHW <- Broadwell, but fails silently on CPUs that don't support it
SMX <- "Safer Mode Extensions" aka Intel Trusted Execution Technology; not used by macOS; I think its absence is actually an artifact of comparing a lower end Haswell laptop CPU and a desktop Kaby Lake CPU; TXT is much older than Kaby Lake.
SGX <- Skylake; removed in newer client CPUs; never used by macOS
HLE <- Broadwell; part of TSX, now disabled by default, support dropped
RTM <- Broadwell; part of TSX, now disabled by default, support dropped
MPX <- Skylake; silently ignored on CPUs that don't support it; support dropped; not included on 10th gen 10nm and some 10th gen 14nm
CLFSOPT <- called clflushopt on Linux; Skylake, but decoded as "rex clflush" on older CPUs which does the same thing without optimizations, so safe
TSXFA <- "TSX force abort", not a real feature; see above
Last edited: