Thank you so much for developing and maintaining this extension! Got it working in my iMac10,1 modded with an AMD WX4150 GPU....
Great job!
Great job!
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
@Syncretic Hello! So with OpenCore Legacy Patcher, ASientientBot, Hedgehog and I have been trying to get acceleration working with TeraScale 2 series. We've had great success for iMac12,1 as well as a Skylake hackintosh but troubles with MacPro3,1. On Mojave, MouSSE works great but we found with macOS Big Sur that we hit an illegal instruction. Specifically
Your driver works great for my RX 570 and the stock drivers, however my HD 5770 hits an illegal instruction only in Big Sur. Likely due to how early AMDRadeonX3000GLDriver and the illegal instruction are called.
Do you have any tips on working around this or perhaps a way to ensure MouSSE is loaded and ready to handle instruction calls? For reference, you can find the binary here: High Sierra's AMDRadeonX3000GLDriver
Extra information regarding hardware setup:
com.apple.AMDRadeonX3000GLDriver's glrATIR800InitMiscTextureInfo calls an SSE4,2 instruction (PCMPGTQ)| Mojave running on HD 5770 with acceleration | Big Sur crashing, calling PCMPGTQ |
|
|
|
Your driver works great for my RX 570 and the stock drivers, however my HD 5770 hits an illegal instruction only in Big Sur. Likely due to how early AMDRadeonX3000GLDriver and the illegal instruction are called.
Do you have any tips on working around this or perhaps a way to ensure MouSSE is loaded and ready to handle instruction calls? For reference, you can find the binary here: High Sierra's AMDRadeonX3000GLDriver
Extra information regarding hardware setup:
- MacPro3,1
- Dual Xeon X5482 Quad Core
- 16GB DDR2 667Mhz (2GBx8)
- Stock Apple ATI HD 5770 1GB
I am crazy busy with work right now, and I'm rarely on here, so please excuse any slow responses. The PCMPGTQ instruction is definitely emulated in MouSSE, so it's just a matter of ensuring that MouSSE is initialized before the PCMPGTQ is encountered. Are either of the kexts (AMDRadeonX3000GLDriver or MouSSE) being injected by OCLP, vs. being linked directly into the kernel? I've never looked into how OC handles injection, but I suspect it would affect the order in which things get initialized.
If either kext is being injected by OC, try linking it directly into the kernel and see if that makes a difference. If it doesn't, I'll have to dig into it when I can find some time.
Upon re-reading, I realized I overlooked your crash log (thank you for including one). The list of binary images therein does not include MouSSE. If the crash didn't occur until WindowServer was running (or trying to run), then MouSSE should almost certainly have been initialized by that point. Are you certain that MouSSE is being loaded?
Thank you so much for the idea regarding installing via S/L/E, unfortunately resulted in the same illegal instruction. I have also verified MouSSE is loaded with kextstat when running Single User off root volume and injected via OpenCore, as well as normal boot in Big Sur with my RX570 running great.
As you noticed, MouSSE isn't present in the logs however other kexts such as Lilu are not as well which I know loaded already due to message logs from verbose.
Do you happen to have any hints as to where else I could investigate?
As you noticed, MouSSE isn't present in the logs however other kexts such as Lilu are not as well which I know loaded already due to message logs from verbose.
Do you happen to have any hints as to where else I could investigate?
I had a thought at lunch. I'm away from my Macs, so I can't test this myself until tonight or tomorrow, so it's just a shot in the dark - in the MouSSE Info.plist, try changing the IOProviderClass string value from "IOResources" to something that loads earlier, like IOPlatformExpertDevice or AppleACPIPlatformExpert. Hopefully that will get MouSSE loaded earlier. (I always meant to revisit the MouSSE loading sequence, but never got around to it.)
Good luck, I'll try to check in later.
Nothing helpful to contribute to this thread other than to say kudos to those working on this. I have a 3,1 with HD5770 which has been collecting dust, and last weekend decided to fire it up and start playing around with OpenCore and OCLP. Right now it's just running High Sierra because of the 5770 (via OCLP 0.1.6 and some custom config tweaks), but I'd eventually like to move it up to Mojave or Catalina if/when support for Terascale 2 is available in OLCP.
Thanks for the suggestion, unfortunately same result. However with IOPlatformExpertDevice as the provider class, I can see it much higher in kextstat than before. With AppleACPIPlatformExpert, it's actually lower on the list
Extra comment, running MouSSE with my RX570 in a clean Big Sur install and running the MouSSEstats results in:
Very odd, as I can see the kext in kextstat
Edit: Looking at dmesg, I find something interesting:
And this is spammed throughout the boot log, I've uploaded the dmesg output here:
gist.github.com
Very odd, as I can see the kext in kextstat
Edit: Looking at dmesg, I find something interesting:
Code:
[ 1.258894]: AAA_LoadEarly_MouSSE::start(IOResources) <1>
[ 1.258902]: MouSSE: CPU does not natively support SSE4.2 and/or POPCNT, attempting #UD hook.
[ 1.258920]: MouSSE: SetTrapHook failed.
[ 1.258929]: AAA_LoadEarly_MouSSE::start(IOResources) <1> failedAnd this is spammed throughout the boot log, I've uploaded the dmesg output here:
HD 5770 Big Sur dmesg output
HD 5770 Big Sur dmesg output. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
Last edited:
Mini update: my RX570 in Big Sur works fine without MouSSE. So been a placebo this whole time that I've thought it was working. Seems the rabbit hole is much deeper than expected
There's the problem - MouSSE is resident but failing to initialize. What version of Big Sur are you using? It looks like it might be 11.3. I have not tested MouSSE on any version of Big Sur myself; several people reported success, so I didn't make it a priority (I'm not running Big Sur on my MP3,1 (yet?)). A glance at the MouSSE source and the 11.3 kernel disassembly suggests that it really should work. This error case only occurs if either of two symbols cannot be located, and both are present in the 11.3 dump I have, so something else is probably going on. I'll have to look into it when I can. In the short term, I don't have any alternatives for you - my current best guess is that 11.3 changed how the symbol table is handled, and my lookup code no longer works, so I'll have to figure out what changed and update MouSSE. That may take some time, given my current schedule.
(If anyone else has experience with MouSSE working/failing on Big Sur, I'd like to hear about it. Please include your Big Sur version number so we can see if there's a cutoff, or just inconsistency (as with some other aspects of Big Sur)).
Correct, was 11.3. I have an 11.0 Beta 7 from back in August I can install and see if the issue is replicable there as well
Thought "Darwin Kernel Version 20.4.0" meant 11.4:
HD 5770 Big Sur dmesg output
HD 5770 Big Sur dmesg output. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
@Syncretic Verified with a macOS 11.0 Beta 9 installer (lost my beta 7), MouSSE is also broken there. Leads me to believe it's always been broken with Big Sur at least on my setup
I got to spend a few more minutes looking at this, and at first glance, it's not pretty. Prior to Big Sur, MacOS just used the standard Mach-O format for symbol lookups (calculate the slide, find __LINKEDIT, find LC_SYMTAB, locate symtab, locate stringtab, find the symbol, Bob's your uncle). It looks like Big Sur makes at least some of those addresses relative to something else, and I'm not yet sure what that is. Unless someone else has already solved this riddle, it will take some time in the debugger to puzzle it out. In the meantime:
I will update MouSSE if/when I can decipher Big Sur's symbol handling (if/when I can find the time to do so).
(Looks like we could both use new eyeglasses, or more sleep! ;-)
MouSSE does not appear to work on any version of Big Sur.
I will update MouSSE if/when I can decipher Big Sur's symbol handling (if/when I can find the time to do so).
I was looking at
root:xnu-7195.101.1 in the picture he posted, which should be 11.3. Now I looked at the dump again, and there's this, right at the top:
Code:
Date/Time: 2021-06-02 18:33:24.353 -0600
OS Version: macOS 11.3 (20E232)Well, we did, in Lilu. Cannot you just use it as a base? Last time I checked MouSSE disassembly it looked suitable for a Lilu plugin. If you lack time, you can open the source code, and we can try to do the port in our spare time. Cheers.
My thanks to @khronokernel and @vit9696 for pointing out that Lilu already handles the Big Sur symbol table changes. Once I worked out what Lilu was doing, I added __PRELINK_TEXT to MouSSE's symbol lookup, and everything looks good. I will post Big Sur-compatible version 0.95 once I've had time to test it a bit (mostly to make sure I didn't break anything on older versions of MacOS).
I remain pressed for time, so before I update the "official" first post, I'm putting MouSSE 0.95 here for what amounts to a public beta. I haven't found any issues on my test platforms, but my testing has been far more limited than usual (and far less than I'm comfortable with, even though it's not a major change). I have no plans to mess with Monterey until it's at least approaching release candidacy, so MouSSE remains untested on that platform (although it should hypothetically work).
If you're so inclined, please try the attached and post successes/failures here (along with a hardware description and MacOS version, please). If no issues are found, I'll promote 0.95 to the first post; otherwise, I'll try to address any reported issues when I can. Thanks in advance for any test reports!
(I note that for simply testing OS compatibility, one can load MouSSE on a 4,1/5,1 and run MouSSEstats to see if it's working, then just unload the kext (it won't ever actually do anything useful on a 4,1/5,1).)
If you're so inclined, please try the attached and post successes/failures here (along with a hardware description and MacOS version, please). If no issues are found, I'll promote 0.95 to the first post; otherwise, I'll try to address any reported issues when I can. Thanks in advance for any test reports!
(I note that for simply testing OS compatibility, one can load MouSSE on a 4,1/5,1 and run MouSSEstats to see if it's working, then just unload the kext (it won't ever actually do anything useful on a 4,1/5,1).)
@Syncretic Fantastic work, both Big Sur and Monterey working!
Here's TeraScale 2 working in Big Sur nicely:
Here's TeraScale 2 working in Big Sur nicely:
Tried it out on DosDude patched Mojave
- Cloned my drive with CCC.
- My standard practice usual before system level updates
- Installed MouSSE 0.95 with KextBeast into L/E
- MouSSE 0.93 lives in L/E
- This is my standard kext installation process.
- Used to upgrade MouSSE to 0.93 on this setup earlier
- KextBeast reported installation went fine
- I then ran MouSSEstats and it reported 0.95 was correctly loaded
- Was able to use mouse and type command etc
- Mac froze afterwards.
- Mouse cursor disappeared and couldn't do anything.
- Seemed fine before running MouSSEstats
- Used power button to restart and it went into a boot loop partway through the process.
- I think around the Stage 2 loading screen
- I rebooted into cloned drive and restored the drive.
Thanks for the feedback!
Thanks for the test report. I've never used KextBeast, so I'm a little unclear on the exact sequence of events. Did you overwrite MouSSE 0.93 with 0.95, link it into the kernel, reboot, run MouSSEstats, then get a freeze? Or did you load MouSSE 0.95 into a running kernel, run MouSSEstats, then get a freeze? If the latter, was MouSSE 0.93 already loaded when you loaded 0.95?
The changes are already wrapped as you describe, and they really only affect initialization; Mojave startup should work exactly as it did in 0.93, and the emulator itself hasn't changed. The idea that you loaded 0.95, successfully ran MouSSEstats, then got a freeze is a bit troubling. Adding to my confusion, I can load 0.95 on my Dosdude1-patched Mojave without issue.
I will review the changes I made, and possibly try compiling with a different version of Xcode. Do you mind if we move this conversation to PM until it's resolved (just to avoid cluttering up this thread)?
@Syncretic Thought I'd mention, tested v0.95 on Mojave as well with our TeraScale 2 patches and still functions great. However I'm using OpenCore for injection so unsure how Dosdude's patches as well as kext loading from Mojave play into things.
Tried 0.95 in Catalina on MacPro3,1 just for a few minutes. I have a GTX 680 GPU so MouSSE isn't usually required except for World of Warcraft Classic. It's interesting to note that World of Warcraft Burning Crusade Classic and World of Warcraft Shadowlands does not require MouSSE (at least with Nvidia - I didn't test AMD).
Third time's a charm (This time installed while booted outside OC but probably not significant):
- It installed fine with KextBeast again but then froze after a while
- I now realise the freeze after running MouSSEstats was not related.
- It was going to freeze anyway.
- After a while, it issued a restart by itself
- On reflection, I don't think I had fully pushed in the power button the first time when the restart happened.
- Probably was coincidental timing
- There was a little boot loop with a black screen.
- Got the startup chime twice.
- I pressed the power button to interrupt and started again
- It then booted into Mojave directly and has been working fine since
- Have been able to reboot a few times via RefindPlus, via OpenCore and directly leveraging DosDude since.
Last edited: