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.
MP 1,1-5,1 MP3,1 (& others?) SSE 4.2 emulation (to enable AMD Metal driver)
- Thread starter Syncretic
- Start date
- Sort by reaction score
Successful install of Monterey using OCLP on MacBook Pro 7,1
Here’s the GPU information if that helps with the development of the acceleration patches
hello khronokernel
is the patch for the Ati 5000 and 6000 series already in the OpenCore Legacy Patcher?
I have a Radeon HD5730 and I'm in the High Sierra with it
I would like to test it too
it is completed with an i5-M460
Thanks for the team work
google translate
I’m curious why you think you need the SSE 4.2 emulation kext when you have a core i5 processor. Even the first generation i5 (which was based on the Nehalem Xeon used in a 2009 Mac Pro) had SSE4.2.
List of Intel Core processors - Wikipedia
good morning,I’m curious why you think you need the SSE 4.2 emulation kext when you have a core i5 processor. Even the first generation i5 (which was based on the Nehalem Xeon used in a 2009 Mac Pro) had SSE4.2.
List of Intel Core processors - Wikipedia
en.wikipedia.org
I don't need to emulate the processor SSE4.2 anywhere I indicated this process!
I do need to use Correctives for Radeon HD5730 in Big Sur to enable QE/CI
sorry if somewhere the comprehension is complicated but i use google translator !!!
This is a very interesting little project. I have a MacPro5,1 that is having trouble running DisplayLink devices and doing some video capture (specifically GIFs) with some apps. Other users with 4,1 and 5,1 MacPros exhibit the same behavior, even with newer video cards (I've tested up to VEGA64). I've been lead to believe from DisplayLink support and other developers that my hardware has some kind of problem with the instructions available and it's simply not possible to run the newer drivers (for example, the DisplayLink kext version works on pre-Big Sur, but the newer drivers will not work with their userland implementation). I'm not sure if QuickSync is the issue since other services from Apple that require it seem to be able to be made to work on these MacPro(5/4,1) models...
...but I thought perhaps you might have some thoughts about what may be going on and where we could look for potential patching or emulation if necessary?
...but I thought perhaps you might have some thoughts about what may be going on and where we could look for potential patching or emulation if necessary?
Maybe a dumb question, but is there any way this could be leveraged to convince a Mac Pro 1,1/2,1 to run something later than El Capitan? My understanding was that the constraint is an SSE4.x requirement in Sierra, while SSE4.x is not available in the MP1,1/2,1's 51xx/53xx CPUs, but that the Sierra kernel did not seem to contain SSE4.x instructions. If the kernel will boot far enough to load this kext, could that be enough to get the rest of the system off the ground? Or am I misunderstanding the approach here?
I'm not trying to be clever and let's be real here, if it was possible to devise any workaround over the SSE4.1 requirement, people would running MacPro1,1/2,1 with Sierra long ago, no?
It's not possible to install a later Harpertown/Wolfdale Xeon, board needs modifications to the hardware and firmware or workaround was ever found for the Sierra SSE4.1 requirement.
Two additions to the observations: Its true that the workarounds/modifications have not yet been found to use SSE4.x capable XEONs on the 1,1 and 2,1 boards. There is still hope as the project is not completely buried.
The other possibility (very tedious and extensive work involved) would indeed be to complete the coverage of missing SSE commands by the MouSSE emulator. I´ve contacted the author about it and it seems generally feasible, but too much work for too low demand. It would have to cover around 40-60 single instructions in various addressing modes. I heard that on one of the major game consoles such a complete emulator has been finished and works, some AMD hackintosh kernel builds make use of (limited!) SSE emulation also.
tldr; no way now or for the near future
In another thread, @lumos asked about a complete SSE4.2 implementation. Let me explain why I'm unlikely to address that anytime soon. (I'm moving the discussion here, so as not to pull the Monterey thread off-topic.)
SSE4.2 consists of 6 or 7 instructions. SSE4.2 "proper" consists of CRC32, PCMPGTQ, PCMPESTRI, PCMPESTRM, PCMPISTRI, and PCMPISTRM. Another instruction, POPCNT, was introduced at the same time as SSE4.2, and is often lumped together with them, even though they're not actually related.
MouSSE implements CRC32, PCMPGTQ, and POPCNT. It does not implement PCMPESTRI, PCMPESTRM, PCMPISTRI, or PCMPISTRM (collectively referred to herein as PCMP?STR?). In addition, MouSSE does not "advertise" the availability of CRC32, PCMPGTQ, or POPCNT, meaning that well-behaved application software (which checks for instruction availability before use) will not benefit from having MouSSE installed. (The MacOS AMD drivers, for which MouSSE was developed, are/were not well-behaved in this regard; they simply assumed SSE4.2 was available and used the instructions without checking. In the future, we'll likely have similar problems with AVX on all pre-MP6,1 systems; the RDRAND problem in Monterey 12.1b1 is another example of presumed instruction availability.)
Most Intel instructions do one simple thing - move data from one place to another, or compare two values, or add two numbers, things like that. The SIMD (SSE) instructions are a little bit more complex; they do mostly the same things, but on groups of values stored in the XMM registers - for example, a single 128-bit XMM register can be treated like 8 separate 16-bit numbers, and a single SIMD instruction can add values to all 8 of those numbers simultaneously. Still, it's fairly straightforward; there's a simple operation to perform, and one or two sets of data on which to perform it - adding, shifting, multiplying, moving, etc.
By comparison, the PCMP?STR? instructions are wildly more complex. They are almost tiny programs unto themselves, tweaked by how they're invoked. The four PCMP?STR? instructions are basically four flavors of one instruction; pcmpEstr? uses explicit-length strings (you pass in the length), pcmpIstr? uses implicit-length (NULL-terminated) strings, pcmp?strI returns an index, pcmp?strM returns a mask. Beyond those differences, what happens "under the hood" is basically the same.
PCMP?STR? uses an Imm8 argument to indicate the sorts of operations to be performed, and what the data looks like - signed or unsigned, bytes or words, the comparisons to be made, and any manipulations made to the results before returning. Let me offer one example:
If the comparison mode is 00 ("Equal Any"), each character of the first string is compared to each character of the second string, and a bitmap is created with the results of those comparisons. If both strings are 16 bytes long, that's 256 comparisons - using a single instruction. After that, any conversions or manipulations that were specified (such as "for each result bit, if the corresponding byte or word of the second operand is valid, invert the result bit, otherwise just copy the result bit") are made, the index or mask is generated, the flags (CF/ZF/SF/OF) are set, and the instruction is finally complete.
The comparison modes can get more complex - one instruction can compare each byte or word of one operand against a series of ranges, similar to
All that complexity makes efficiency a problem. PCMP?STR? can perform those 256 comparisons and the other manipulations in just a few clock cycles; the best-case emulation will be several orders of magnitude slower. Developers use the SIMD instructions to gain speed, and if there are any timing dependencies (other than an impatient user waiting for their program to respond), emulating these instructions will probably produce very unpleasant results.
When I designed MouSSE, I created an outline for efficiently implementing the PCMP?STR? instructions. Just looking at that outline gives me a headache, and perhaps the brief example above tells you why (alternatively, scroll through the second link below). Absent some compelling reason, or the unexpected onset of masochistic tendencies, I don't plan to implement the PCMP?STR? instructions. They're certainly very powerful instructions, which makes one wonder why they're not more widely used - until you realize that their complexity makes it difficult to wrap your head around them. Beyond trivial examples, using them effectively requires effort, and most developers (and compilers) seem to prefer the simplicity of the old-school
(If you're craving more details, this link contains Intel's discussion of the Imm8 control byte, and this link offers a reasonable overview of the PCMP?STR? instructions - a quick scroll down the page of that second link will give you a graphical indication of the complexity involved.)
SSE4.2 consists of 6 or 7 instructions. SSE4.2 "proper" consists of CRC32, PCMPGTQ, PCMPESTRI, PCMPESTRM, PCMPISTRI, and PCMPISTRM. Another instruction, POPCNT, was introduced at the same time as SSE4.2, and is often lumped together with them, even though they're not actually related.
MouSSE implements CRC32, PCMPGTQ, and POPCNT. It does not implement PCMPESTRI, PCMPESTRM, PCMPISTRI, or PCMPISTRM (collectively referred to herein as PCMP?STR?). In addition, MouSSE does not "advertise" the availability of CRC32, PCMPGTQ, or POPCNT, meaning that well-behaved application software (which checks for instruction availability before use) will not benefit from having MouSSE installed. (The MacOS AMD drivers, for which MouSSE was developed, are/were not well-behaved in this regard; they simply assumed SSE4.2 was available and used the instructions without checking. In the future, we'll likely have similar problems with AVX on all pre-MP6,1 systems; the RDRAND problem in Monterey 12.1b1 is another example of presumed instruction availability.)
Most Intel instructions do one simple thing - move data from one place to another, or compare two values, or add two numbers, things like that. The SIMD (SSE) instructions are a little bit more complex; they do mostly the same things, but on groups of values stored in the XMM registers - for example, a single 128-bit XMM register can be treated like 8 separate 16-bit numbers, and a single SIMD instruction can add values to all 8 of those numbers simultaneously. Still, it's fairly straightforward; there's a simple operation to perform, and one or two sets of data on which to perform it - adding, shifting, multiplying, moving, etc.
By comparison, the PCMP?STR? instructions are wildly more complex. They are almost tiny programs unto themselves, tweaked by how they're invoked. The four PCMP?STR? instructions are basically four flavors of one instruction; pcmpEstr? uses explicit-length strings (you pass in the length), pcmpIstr? uses implicit-length (NULL-terminated) strings, pcmp?strI returns an index, pcmp?strM returns a mask. Beyond those differences, what happens "under the hood" is basically the same.
PCMP?STR? uses an Imm8 argument to indicate the sorts of operations to be performed, and what the data looks like - signed or unsigned, bytes or words, the comparisons to be made, and any manipulations made to the results before returning. Let me offer one example:
If the comparison mode is 00 ("Equal Any"), each character of the first string is compared to each character of the second string, and a bitmap is created with the results of those comparisons. If both strings are 16 bytes long, that's 256 comparisons - using a single instruction. After that, any conversions or manipulations that were specified (such as "for each result bit, if the corresponding byte or word of the second operand is valid, invert the result bit, otherwise just copy the result bit") are made, the index or mask is generated, the flags (CF/ZF/SF/OF) are set, and the instruction is finally complete.
The comparison modes can get more complex - one instruction can compare each byte or word of one operand against a series of ranges, similar to
if ((x >= 'a' && x <= 'z') || (x >= 'A' && x <= 'Z') || (x >= '0' && x <= '9') || (x >= 141 && x <= 157) || ..., or it can search for one operand as a substring of the other (like strstr(), or "find the needle in the haystack"). And, of course, it can do a simple "a == b" comparison as well. Then each of these is followed by whatever conversions or manipulations are indicated in the Imm8 argument, all in the same single instruction.All that complexity makes efficiency a problem. PCMP?STR? can perform those 256 comparisons and the other manipulations in just a few clock cycles; the best-case emulation will be several orders of magnitude slower. Developers use the SIMD instructions to gain speed, and if there are any timing dependencies (other than an impatient user waiting for their program to respond), emulating these instructions will probably produce very unpleasant results.
When I designed MouSSE, I created an outline for efficiently implementing the PCMP?STR? instructions. Just looking at that outline gives me a headache, and perhaps the brief example above tells you why (alternatively, scroll through the second link below). Absent some compelling reason, or the unexpected onset of masochistic tendencies, I don't plan to implement the PCMP?STR? instructions. They're certainly very powerful instructions, which makes one wonder why they're not more widely used - until you realize that their complexity makes it difficult to wrap your head around them. Beyond trivial examples, using them effectively requires effort, and most developers (and compilers) seem to prefer the simplicity of the old-school
rep string instructions. I have encountered few instances of these instructions "in the wild," regardless of the operating environment (MacOS/Windows/Linux).(If you're craving more details, this link contains Intel's discussion of the Imm8 control byte, and this link offers a reasonable overview of the PCMP?STR? instructions - a quick scroll down the page of that second link will give you a graphical indication of the complexity involved.)
Thank you very much for this in-depth post, @Syncretic , it's a pleasure to read as it really gets to the bottom of the problem and explains it so well. ?
Thank you very much @Syncretic for your in-depth post and sorry for my late answer (I haven't notice your post until today, thank you also to @Hackintosh HD to notify me).
(Posting here because it's somewhat relevant, and to keep from polluting other threads)
I was recently asked in PM about spoofing the SSE4.2/POPCNT feature flags in
Intel CPUs have an instruction called
OpenCore can spoof
Altering the
I can only think of one narrow instance (on a Mac Pro 3,1) where feature spoofing might be worthwhile. I have not tested this, and it may not work at all, so I advise against trying it on an essential or production system. As I've explained above, MouSSE emulates all of SSE4.2 except the PCMP?STR? instructions. I am not aware of any PCMP?STR? instructions in MacOS (although that doesn't mean they don't exist), so it's entirely possible that MacOS wouldn't panic if SSE4.2 was advertised as available on an MP3,1 with MouSSE installed. (I should note a race condition here - if SSE4.2/POPCNT is advertised, and the kernel or another kext (such as APFS) attempts to use SSE4.2 before MouSSE is initialized, a panic will result.) If some application requires only the instructions that MouSSE emulates (and none that it does not), MouSSE should be adequate to allow that software to run. Due to the unknowns and timing/race risks, setting the SSE4.2/POPCNT
That's a lot of "ifs", but while it seems unlikely, it's a plausible scenario.
In any case, I'd avoid spoofing nonexistent
I was recently asked in PM about spoofing the SSE4.2/POPCNT feature flags in
CPUID, and now I see that @Dayo is looking at it as well. Here's some quick background, and my thoughts on the matter.Intel CPUs have an instruction called
CPUID, which allows software to query the CPU about its capabilities. CPUID was introduced with the first Pentium in 1993, and since then, a great many features have been added, so the CPUID instruction has had to evolve over time. Thus, a single call to CPUID on a modern Intel CPU does not return all relevant information; one must call CPUID repeatedly (it takes dozens of CPUID calls to fully enumerate the CPU's functionality), using different arguments, to fill out the complete picture. To simplify things, MacOS fetches all of the CPUID data at boot time and stores it such that a simple API call can return any desired information without having to jump through the hoops of using CPUID directly.OpenCore can spoof
CPUID information by altering the MacOS data structures and preventing MacOS from overwriting the altered data. This is effective for programs that utilize the MacOS API for retrieving CPUID information. Unfortunately, there is no reasonable way to intercept the CPUID instruction itself on a Harpertown/Nehalem/Westmere/Gulftown CPU; therefore, if a program directly executes the CPUID instruction (forgoing the MacOS API), the true (unaltered) CPUID data will be returned, and the program will behave accordingly. Spoofing such a program requires either a tweakable VM or patches to the program itself.Altering the
CPUID data to make a non-existent feature appear to be present (such as SSE4.2/POPCNT on a Mac Pro 3,1 or AVX/XSAVE on any pre-6,1 Mac Pro) is generally a bad idea. Advertising a feature that does not exist is an invitation for other software to use that feature; any kernel-level software that tries to use SSE4.2 or AVX on a MP3,1 will immediately panic, and there are known instances of both SSE4.2 and AVX code in MacOS. Worse, that panic could corrupt the disk - APFS in particular is known to contain both SSE4.2 and AVX code that will be used if those features are advertised as available; depending on timing, the resulting panic could cause data loss. Enabling the XSAVE/OSXSAVE feature flags on any pre-AVX system will cause a panic because the kernel will attempt to use the non-existent XSAVE*/XRSTOR*/XGETBV/XSETBV instructions during context switches. In short, enabling the CPUID flags for any non-existent (and un-emulated) features sets up a disaster waiting to happen.I can only think of one narrow instance (on a Mac Pro 3,1) where feature spoofing might be worthwhile. I have not tested this, and it may not work at all, so I advise against trying it on an essential or production system. As I've explained above, MouSSE emulates all of SSE4.2 except the PCMP?STR? instructions. I am not aware of any PCMP?STR? instructions in MacOS (although that doesn't mean they don't exist), so it's entirely possible that MacOS wouldn't panic if SSE4.2 was advertised as available on an MP3,1 with MouSSE installed. (I should note a race condition here - if SSE4.2/POPCNT is advertised, and the kernel or another kext (such as APFS) attempts to use SSE4.2 before MouSSE is initialized, a panic will result.) If some application requires only the instructions that MouSSE emulates (and none that it does not), MouSSE should be adequate to allow that software to run. Due to the unknowns and timing/race risks, setting the SSE4.2/POPCNT
CPUID bits for general usage is inadvisable, but it might work. However, it's possible that the following set of conditions might exist (which is what I was asked about in PM):- An application's installer performs a capability check for SSE4.2/POPCNT using the MacOS API (and does not directly execute the
CPUIDinstruction). This installer either uses no SSE4.2 itself, or it only uses SSE4.2 instructions emulated by MouSSE. - The application being installed either uses no SSE4.2, or only uses SSE4.2 instructions emulated by MouSSE, and it does not perform any
CPUIDchecks itself - it assumes that SSE4.2 is available by virtue of the fact that its installer succeeded.
That's a lot of "ifs", but while it seems unlikely, it's a plausible scenario.
In any case, I'd avoid spoofing nonexistent
CPUID features if possible. There's little or no advantage, and a whole lot of potential drawbacks.Have you looked at Intel SDE?
https://www.intel.com/content/www/us/en/developer/articles/tool/software-development-emulator.html
It says it can change the function of CPUID in a process. I have not check compatibility. Maybe it can't do that for Harpertown/Nehalem/Westmere/Gulftown CPU like you say.
The last supported macOS version they mention is Big Sur. @freqrider says it doesn't work with Monterey #1,113
He was able to use it to play Doom Eternal on a MacPro3,1 but that was in Windows 10
There's some videos:
https://forums.guru3d.com/threads/how-to-get-intel-sde-sse-emulator-to-work-with-cod-warzone.434306/
I usually use the adjectives "(un)reasonable" or "(im)practical" when discussing the inability to trap
CPUID; of course, those are subjective terms, and there may be use cases where my view of "unreasonable" or "impractical" doesn't apply. The Intel SDE appears to be a useful development/debugging tool, but impractical for most real-world use. It effectively single-steps through a given program, throwing an exception after every instruction is executed, analyzing the instruction to see if other action (such as emulation) should occur, performing any such actions, then repeating the process. The overhead is enormous, and for most purposes, the slowdown is intolerable (again, a subjective measure). If you just use it for a number-crunching application where you're concerned with the final output more than the runtime, it's fine - but if you want real-time interaction with some other device or a human, frustration is all but guaranteed. (I noticed that the Doom Eternal video conveniently ended before the game actually ran, and the Final Fantasy video showed in-game frame rates mostly between 0 and 5 - again, it's subjective, but a game running at 0-5 FPS is effectively unplayable, or at least certainly not enjoyable.) Of course, if you have a monster PC that's overclocked, you might get satisfactory (or at least acceptable) results - but that's not the case with our old Mac Pros. And, of course, the SDE is only useful for applications; if the kernel or a kext requires emulation, the SDE is not a solution. (To directly answer your question, I looked at SDE years ago and found it lacking, and I haven't followed up with it since then.)For the "installer is the only roadblock to usage" scenario I described in my previous post, the SDE is probably an adequate solution, assuming the installer runs without incident on the SDE. It might even be good enough to run the application itself, depending on the use case - though I'd be surprised if it provided a satisfactory user experience.
Starting with Ivy Bridge, Intel introduced VT FlexMigration, which allows virtualization of the
CPUID instruction. Of course, that doesn't help the Harpertown/Westmere families, and it's currently irrelevant for any legacy emulation (such as MouSSE) because Ivy Bridge+ natively supports SSE4.2, AVX, F16C, and RDRAND. It sure would be handy to have that feature on our older CPUs, though.
Interesting! I installed AAAMouSSE4.2.kext io loading with openCore. Perhaps it is not loading in time, creating the panic with the “J” cpuid flag. I will try loading the kect with OC and see if it makes a difference. (At my own risk!
Idea is to spoof it when the feature does exist as when being emulated but not being advertised on inquiries.
A cMP is using an effective emulator for SSE4.2 features such as AAAMouSSE but when any application asks whether SSE4.2 Feature X is available, the answer it gets back is "No, SSE4.2 Feature X is not available".
Would be nice to be able to change that to "Yes, SSE4.2 Feature X is available" ... without the kernel taking everything down as a result though. Seems an ideal way would be for AAAMouSSE to do the spoofing in addition to the emulation it does.
This seems to be the case with VMWare and possibly Photoshop. This would limit usefulness of the spoofing even if the other chalenges can be overcome ... but baby steps though.
Someone please help. I am not familiar with the terminal, but I seemed to have successfully followed the steps. The terminal lit up with text and all looked promising until I tried my card after rebooting and it just sat at a white screen. What I did...put file folder titled "MouSSE_Release" in my desktop
Typed: cd ~/Desktop/MouSSE_RELEASE [PRESSED ENTER]
and then typed the rest of the commands as instructed. I waited for a bit until text stopped and reboot my Mac. Tried it with the card and no go. I then used the MouSSEstats to check on it. It says it does not appear to be loaded. What do I do?
Typed: cd ~/Desktop/MouSSE_RELEASE [PRESSED ENTER]
and then typed the rest of the commands as instructed. I waited for a bit until text stopped and reboot my Mac. Tried it with the card and no go. I then used the MouSSEstats to check on it. It says it does not appear to be loaded. What do I do?
You seem to try to add the MouSSE kext manually? Several more steps would be needed to get that going, depending on the macOS you´re running... (correcting permissions, rebuilding kernel caches, disable SIP, allow unsigned kexts, etc.).
If you´re on some older OS, you might better try a kext utility (as i.e. kext wizard) to include new kext(s) to your system. On newer macOS, just use the Open Core Legacy Patcher, it will do all tasks for you and also includes the SSE emulator.
Thanks for the advice. I have High Sierra running on my 3,1 with the Dosdude patcher. I'm going to check that open core patcher out as well. Right now I'm looking at just going with the DosDude Catalina patcher with SSE4.2 emulation. I guess the drivers are better for RX 580 anyways...
The mentioned kext tools work for High Sierra.
Depending on what (older) software you need to use (or in case of 32bit-only apps possibly do not rely on), I´d suggest moving on to Big Sur or Monterey on your MP3,1. Unsupported machines support is much better, up to date and the 3,1 is a still very capable machine once you have added a metal card and SSD. If all your programs run on Monterey, there is no real practical disadvantage* in comparison to High Sierra or Catalina.
* one exception comes to my mind, though: iSight FireWire is missing in action, but not yet buried (perhaps there are future patches possible)