Jump to content

metacollin

Members
  • Content Count

    8
  • Joined

  • Last visited

About metacollin

  • Rank
    InsanelyMac Protégé

Contact Methods

  • Website URL
    https://electropi.mp

Profile Information

  • Gender
    Male
  • Location
    New Mexico, USA
  • Interests
    Electrical Engineering, Formal Linguistics, Deep Learning Badmotherf––kerdom

Recent Profile Visitors

1,058 profile views
  1. metacollin

    DSDT+SSDT questions that baffle me

    OK, so you seem a bit confused about the nature of ACPI tables. The DSDT is an ACPI table that is generated from pre-made templates in the BIOS, and changing BIOS settings can change the contents of this table. SSDTs are tables that contain some extra stuff not in the template, and are simply concatenated to the end of the DSDT during boot. So you can pretend that each SSDT is literally just going to be copied and pasted to the end of the DSDT. The first one first, then the second one will be pasted after the first one, so on and so fourth. It's as simple as that. So there is just one table. Clover applies patches to it. DSDT and SSDTs are just pieces of that single table. Even if you applied the patch just to DSDT, it would effect everything, because it is a single table. Clover will check to see if the SSDTs need patching and will patch it, but usually there is nothing relevant contained in the SSDTs to any of the patches clover can dynamically apply. Now, as for which table is used, there is always one table. Clover does not care about the origin of the table. It does everything exactly the same regardless of where it came from. If you provided one you patched manually, it will use that one. If you didn't, it will use the one from the BIOS. The one it uses is the one it patches and does everything to. Finally, you can have as many SSDT tables as you want. They don't have to replace the built-in ones (and often, you don't want them to). For example, I have 9 different SSDTs, all of them custom, but my system only has 2 on its own. And even that is just personal preference, there is no reason I couldn't copy and paste them all into one SSDT and use it that way. I like to keep it more organized, though. So I am confused by your third question. You say there is no CpuPm table anywhere. And? If there was a table already, you'd have to drop that SSDT or there would be a conflict. I would hope that the same table doesn't appear anywhere since you're adding it youtself, or you'd have a ACPI namespace conflict and probably wouldn't even be able to boot. I also don't understand what you mean about 'merging in'. ssdtprgen generates an SSDT.aml file. You put it in your /Volumes/EFI/EFI/CLOVER/ACPI/patched directory. I don't see what the issue is. I also don't understand why you are trying to have clover inject an ID that your wifi card already has. This will do nothing, or worse, break things. If it has that ID, then macOS will read it's ID as such. Injecting it via clover will, at best, make exactly the same thing happen. You're replacing a street sign with the exact same street sign.
  2. metacollin

    Clover test and patches for Polaris GPU

    STRT="sh" END="it" echo "No $STRT$END." If we knew how to read it correctly, we wouldn't be manually setting the VRAM amount. Why we can't get a valid VRAM value at the only place we know to look is the million dollar question. No they are not. They are. You're description of the bit fields of the BAR registers is totally correct. But there is a difference between reading registers incorrectly, and hard-coding the correct way to read registers. AMD/ATI cards have known BAR layouts. For newer cards, it is as follows: BAR0 Low bits ━┓ ┣━ 64-bit MMIO Region - This is the VRAM Aperture. Since GPUs need to maintain 32-bit address space backward-compatibility, ┃ one access the VRAM via an 'aperture', which can be thought of as a moving address 'window', allowing a portion of the ┃ available VRAM to be mapped to a single MMIO region. Also, I believe if an IGPU is present, but the discreet card is primary, ┃ the IGPUs VBIOS is placed at the start of this aperture, followed by the beginning of the VRAM passthrough BAR1 High bits ━┛ BAR2 Low bits ━┓ ┣━ 64-bit MMIO Region - This is the doorbell aperture MMIO region. Doorbells are how the driver queues up rings (jobs), ┃ manages fences (jobs that depend on the completion of other jobs first), etc. BAR3 High bits ━┛ BAR4 ━━━━━━━━━ IO Space, 0x100 in length. Allows direct GPIO control. This is generally used for things like voltage control, power management, reading sensors, sort of hardware 'janitorial' stuff. BAR5 ━━━━━━━━━ 32-bit MMIO Region, always 0x00040000 in length. This is always the actual register base address. Every card from Bonaire onwards has had this layout, and this includes the latest Polaris GPUs. And this is exactly how clover uses them - and that way is correct. Indeed, it is hardcoded, and I agree, in a perfect world, it ought to figure out as much as possible algorithmically rather than being hard coded. But the problem does not lay here, at least not directly. Clover correctly gets all the regions right, and you may confirm this by dumping the pci config spaces from your BIOS' native EDK2 shell. It seems like there is a lot of misunderstanding by people (myself included) and people (again, myself included) exploring things that aren't important. Let me try to consolidate what we know and what is or isn't useful: 1. There is no incompatibility between Nvidia and AMD cards in the same system. I'm currently running a GTX 960 as my primary 'helper' card, along with my display hooked up to an RX480. I can switch between the two without issue. Both drivers are enabled and working. I can use OpenCL on both, and CUDA on the Nvidia GPU. There is some sort of myth about there being problems, but they're aren't. Testers, don't think you need to use a specific type of helper card, because you don't. Anything will do. 2. This issue actually effects Tonga and newer AMD cards on Sierra, including real Mac Pros. The cheese grater ones. Mac Pros do not have any boot screen, presumably because the driver won't work if those cards are initialized by EFI. I have confirmed this by suffering a similar issue with a helper card set as primary, but using my card in EFI mode. 3. This problem was seen on Linux as well. Kernel 4.7.4 had a strange problem where using rEFIt or grub EFI would result in a black screen once the amdgpu driver loaded. The problem was fixed by a driver patch that was part of the changes from 4.7.4->4.7.5. So that problem stopped after kernel version 4.7.5. It might be possible that a similar issue was, and continues to be, present in Apple's own driver. Being Apple, it is possible that this bug will never be fixed until the universe has suffered heath death. 4. We have an advantage in that we ought to be able to display video using legacy mode in Clover, yet this does not work either. This makes me wonder if the bug is related to the one in the linux kernel at all. It really seems that the only way MacOS can correctly reach the desktop is if No video at all has yet been displayed on the card, regardless of the origin. 5. The screen is displaying black. This is distinct from the display being inactive. It is inactive during a boot that will reach the desktop, but if you have video during boot, it will hang right before reaching the desktop, but the screen will be active. It will simply be displaying all black, however. That means this is not some connector issue. The connector is working, the EDID has been read, the card has a framebuffer attached, and HDMI/DVI/DisplayPort/whatever signals are being sent in just the right way for that display, and those signals are telling it to display black. A lot of things that people seem to be spending a lot of time on must already be working correctly for this to happen. That's a dead end. Don't waste time on it. 6. If I boot with my helper card primary, but EFI active, I will get video during boot. Sierra still hangs without ever reaching the desktop, but ssh works. The OS boots, but the graphics driver is stuck. However, in this case, the screen is not blank - a characteristic pattern of dots always appears in the same pattern, and same location, on my screen. They are patterned in a way that looks like the driver was trying to write to some adjacent registers somewhere in an MMIO region, but they instead went part way into the framebuffer. Also, if I relocate the boot console to the second (RX480) display, the buffer is not cleared - it will display the last frame before the hang indefinitely. HOWEVER, those dots will overwrite whatever is displayed, along with a small bar across my entire screen. This would be consistent with writing a large continuous block of zeros to the frame buffer. It really seems like the driver is getting confused about where the framebuffer object is actually located in the VRAM aperture. It seems like maybe the act of displaying video prior to the driver loading is allocating a framebuffer in the VRAM aperture where the driver expects to find nothing. More on that later, potentially. I am still slogging through the linux amdgpu drivers, which as fantastically documented as they are (note: I say that with the heaviest sarcasm), is going to take more time. I might be chasing nothing at all, who knows. 7. The actual reason the screen is black/frozen? The GPU is hung. There are repeating "IOAccelSurface2::surface_unlock_options(enum eLockType, uint32_t): surface is not locked" faults, several in a row. It looks like it is locking a non-existent framebuffer/surface, presumeably after attempting to write to it. And, indeed, besides that, I see repeating "IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): prodding blockFenceInterrupt" faults. That means it is waiting for some critical enqueued task to finish on the GPU (like finishing a pass on a framebuffer). Only, it waits like this forever. The GPU never finishes. If I wait long enough, it eventually tries to reset the GPU, but gets a PCIE channel hardware error. The GPU isn't just hung, its pretty much {censored}ed. Nothing will un-{censored} it except a full reboot. So the question is: what is causing the driver to lose it's mind and apparently not even be able to create one framebuffer correctly if the card has been displaying video in EFI mode, or in legacy mode, VGA/VESA video? What has changed on the card? The IO and MMIO regions are the same either way. And those are correct regardless. No issue there. This is gonna be a {censored} chafe to fix. Characteristic dots:
  3. metacollin

    AMD Polaris IDs on Sierra / High Sierra

    You need a helper card because the RX480 cannot be the primary GPU. If it is the primary GPU, the driver crashes when it tries to initialize the card and you get a black screen. The only workaround at the moment is to set your primary GPU as the the 'helper card' in your BIOS, or if that is not an option, usually a motherboard will make the card in the first PCIE slot the primary. So make sure your RX480 is NOT in this slot, and is in a different one. The goal here is to make the computer/clover use the helper card. You do not need anything plugged into it, but you should have your display plugged into the RX480. If you did it correctly, you will get NO video on your display from the RX480 until right before the macOS desktop/login screen appears. No BIOS post, no clover, no boot progress bar, nothing. That is because it is sending the video to the 'helper' card because it is primary. If the RX480 is left untouched/unposted, then when the macOS AMD4100.kext driver loads (right at the end of the boot process), you will magically get accelerated video and the RX480 will work and you can ignore the helper card. If you run into problems during boot, you have to manually plug your monitor into the helper card and see what's up. It's a less than ideal solution, but its what works for now.
  4. metacollin

    Clover test and patches for Polaris GPU

    RX480 on 2008 Mac Pro, sleep working: RX480 on hackintosh, sleep not working: ATY_GPU offset 0x0000-0x0200 ATY_GPU offset 0x0000-0x0200 0x0000: C0500198 FFC9BC30 00000001 00000000 00000000 00000000 00000003 00000000 0x0000: C0500198 1C2DE4BB 00000001 00000000 00000000 00000000 00000003 00000000 0x0020: 00000000 00000000 00000000 00000000 100100BB 00000010 100100A2 5A8814E6 0x0020: 00000000 00000000 00000000 00000000 100100BB 00000014 100100A2 5A9816E6 0x0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00C0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00C0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0100: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0100: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0120: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0120: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0140: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0140: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0180: 00000100 00000000 FFFFFFFF 00000000 00000000 00000002 0000000B 00000000 0x0180: 00000100 00000000 FFFFFFFF 00000000 00000000 00000002 0000000B 00000000 0x01A0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x01A0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x01C0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x01C0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x01E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x01E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x0200: E00030A4 0003001E C010010C 9C6A81C0 00000000 AAAA5555 C030000C 08005E60 0x0200: E00030A4 0003001E C010010C AF6F85BE 00000000 AAAA5555 C030000C 08005E60 ====================================================================================================================================================================== RX480 on 2008 Mac Pro, sleep working: RX480 on hackintosh, sleep not working: ATY_GPU offset 0x1700-0x1750 ATY_GPU offset 0x1700-0x1750 0x1700: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x1700: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x1720: 00000000 00810000 00000000 00000000 00000000 00000000 00000008 00001000 0x1720: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x1740: 00000200 00000000 00000000 0000ECD7 00000000 00000000 00000000 00000000 0x1740: 00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ====================================================================================================================================================================== RX480 on 2008 Mac Pro, sleep working: RX480 on hackintosh, sleep not working: ATY_GPU offset 0x5400-0x5450 ATY_GPU offset 0x5400-0x5450 0x5400: 00000000 00000001 00000000 00000000 00000000 0000001A 00000002 00000006 0x5400: 00000000 00000001 00000000 00000000 00000000 0000001A 00000002 00000006 0x5420: 00000000 00000000 00002000 80000000 00000100 00040000 00000000 00000000 0x5420: 00000000 00000000 00002000 C0000000 00000100 00040000 00000000 00000000 0x5440: 00000000 00000000 00000000 00000000 00018003 00000000 00040040 4010E110 0x5440: 00000000 00000000 00000000 00000000 00018003 00000000 00040040 4010E110 And here is a visual diff for your convenience: https://www.diffchecker.com/8XjpxBUb
  5. metacollin

    Clover test and patches for Polaris GPU

    Its already possible to use Polaris cards without an IGPU. I'm doing it right now. I have no IGPU at all (Xeon processors) and the only PCIE card installed is an RX 480. The problem is it is impossible to have preboot video AND acceleration. If the card is posted already, Sierra stops booting when it loads the X4100 kext (and the screen dies, and the RX480 fans usually slow down or turn off). If the card is uninitialized, then the X4100 kext effectively causes it to post almost at the end of the boot process and suddenly you have video and working graphics acceleration. This means, however, that you cannot actually see clover, the BIOS screen, or anything else. No video until OS X is mostly finished booting. Obviously this is less than ideal . All one has to do is prevent the card from getting posted by the BIOS/clover. One way is to have another GPU as primary, but not the only way. What I did was flash my card with a new ROM that doesn't have the legacy section anymore, then tell my bios to force the legacy option rom to be loaded. This makes it try to load something that isn't there, so the card fails to post, and the machine behaves as if it has no card installed at all. Assuming nothing gets screwed with the OS X boot process though, I eventually am rewarded with working video . Since many of the polaris GPUs have dual roms selectable by a switch, I have a working legacy rom saved in the second rom slot. If something gets screwed and OS X can't boot, I can flip the switch to get working pre-boot video and make any changes needed in clover, the BIOS, or whatever. And OS X will boot just fine as long as the X4100 kext is prevented from loading, but for working acceleration, I have to switch back to the 'hold onto your butt' (to quote Samual L Jackson from Jurassic Park) method and stare at a black screen hoping it boots. Note, I strongly discourage anyone from flashing their card, I did it because I have the ability to flash the ROM chip manually if I accidentally bricked the card. It's also possible to unbrick them by soldering a wire to short two pins on a SOIC-8 chip (the SPI flash rom). The leads are spaced 1.27mm apart, so be comfortable with that idea before attempting any thing like that . For most people, its just not worth it, its better to use your IGPU as primary or just buy a cheapo $20 video card if you don't have an IGPU.
  6. metacollin

    Clover test and patches for Polaris GPU

    Hi, I've been following this closely, and trying to find a solution myself. I have a C612 workstation running Sierra 10.2.2 and avoid modifying kexts etc. at all costs. I have not edited my X4100.kext at all, I instead use SSDT injection to disable all devices that slot has PCI routes to by setting their _STA to zero. I then inject my own device named GFX1 with a fake ID, 0x67FF in my case, solving the MacPro gfx0 unload problem and matching the X4100.kext in one update-proof go. I also have no IGPU at all of course. I am competent in simpler embedded systems (ARM cortex-3 micros and simpler mostly) and have been adding my own debug info to clover and testing it (without any useful results =/) but I am just trying to say I can help test whatever and will probably know what it is you want me to do. Oh yeah I have an RX 480. So, some things I've noticed: 1. Non-primary GPUs will display black while Clover is booting/booted. This is different from what happens with an RX480. By display black, I mean there is a valid video signal driving the display and telling it to show black pixels. However, the RX 480 isn't displaying black, it's not displaying anything - there is no valid signal coming out of the ports at all. I wonder why this is? Might be nothing but mentioning it in case it's useful. 2. I have a dual link 2560x1440 DVI display, and I've noticed that when I inject my EDID, when the X4100 kext loads, instead of the RX 480's output going dead suddenly, the bottom half of my display flashes white (I have some 240 fps video if you think it's worth the time) before the video input dies. so something is making only one of the two dual link channels briefly go all white. This does not happen at all normally, normally video just cuts out without any flash etc. 3. The not finding a valid rom might not be invoked. This happens on Linux too but doesn't cause any problems. Also, all of this happens if I load a valid vbios from my EFI partition or don't. 4. The Polaris cards have a hybrid rom, which is a UEFI/GOP module in addition to a traditional legacy rom. The UEFI module acts as a loader for the legacy module. Note, both of these rom sections are digitally signed. The UEFI module verifies the signature of the legacy rom and only loads it if it passes. The UEFI module's signature is only verified by the computer's BIOS itself if secure boot is enabled, so that isn't really relevant. Anyway, I altered my legacy rom section such that it would fail validation but still work fine, then flashed that onto my card. I then forced my BIOS to "UEFI only" mode, which of course resulted in no video coming out of the card. The legacy rom wouldn't load, and CSM/any loading of it by the mobo itself wasn't allowed. Only, if I wait, video happily appears along with OS X's login screen, as soon as the X4100 kext loads. This is with the RX 480 as primary, and a invalid (in terms of the signature) legacy rom section. I know recent Mac pro's EFI will actually find and load legacy rom sections of cards, removing the need of having an EFI section to work. This is my thinking: is it possible that when the UEFI/GOP module loads the legacy rom, it remaps it? Or remaps something? I don't think this is a connector problem - though that might be an issue on its own, I don't know. If the frame buffer doesn't match connectors, the video cuts out entirely but OS X still boots. You have no screen but you can mash keys and hear sounds. That is not what occurs with the RX 480. It halts, immediately. All hard drive I/O stops mid boot, and that's the end. On rare occasions, my machine (or rather The xnu kernel) will actually manage to automatically reboot when this happens, just like certain kernel panics. This outcome is rare though, and usually my machine just locks in permanent limbo. anyway, i dunno if any of that is at all useful. But if you need me to test anything or want any information from me, let me know. Oh, I did prevent the X 4100 kext from loading and booted without accelerated video, and can confirm that all those extra properties, the frame buffer, connector injection seems to work correctly. I would an ioreg dump be useful? Though, It also likely means that it's not the culprit, but I am kind of out of my element. Anyway, thank you very much Slice and Mork vom Ork for the time you've given towards figuring out this problem. I know Slice isn't even really interested, but trying to get the sleep/wake issues with ATI cards sorted, so a double thanks for going out of your way on this side problem.
  7. metacollin

    AMD Polaris IDs on Sierra / High Sierra

    This is utter nonsense, please ignore it. The X99 and C612 chipsets work great and are by far the easiest chipsets I've hackintoshed, and don't require a single specialized DSDT patch to be fully working. As I am typing this from a Dual Xeon V4 C612 hackintosh running Sierra that I use in a production environment, I can empirically demonstrate that wardoc doesn't know what he's talking about. This is the most stable and smooth computer to run OS X I've ever used, and I used a 2008 Mac Pro (like, a real one) for 8 years before this current hackintosh rig. I am sane, and I would recommend it over any other chipset. It just works. Everyone, this has nothing to do with an IGPU. At all. This has nothing to do with Apple's RX 480 support. This is entirely an issue with clover. I have an RX 480, and I am also a registered macOS developer member ($100 for the 'honor' =P) and am running Sierra 10.12.1 Beta 3. As stated earlier, I have a dual Xeon Rig, with no IGPU to speak of, or even the possibility of one. Fortunately, that isn't at all necessary to get the RX 480 working. This is a clover issue, something it is doing to ATI cards but only if they're the 'boot' GPU (primary) is somehow incorrect and causing the X4100 kext to panic during the initialization process of the RX 480. It's easy to tell this is what is happening. There is a subtle but important difference between the various ways one might get a black screen. If it was a problem with the kext, then it would simply fall to load and fallback to the unaccelerated frame buffer. Or, similarly, if it was something along the lines of the MacPro6,1 GFX0 unload issue, that results in a true black screen. i.e., there is a video signal coming out of the card driving the display, but telling it to show nothing. Or more specifically, to show 000000h for every pixel (black). Instead of a display showing black, this RX 480 issue is presenting as an actual lack of video signal entirely, but only after the X4100 kext tries to load. After this, all system I/O halts, which would only occur if there was a panic. Depending on your setup and the state macOS is in when a panic occurs, this can result in an indefinite stall or an automatic reboot. I have seen my machine automatically reboot with a dead screen (note dead screen vs black screen. Black screen is still a working GPU, dead screen is no video signal at all) as well as stall in that state. Regardless, a panic is the only explanation for all the symptoms. This panic does not occur on MacPro5,1s for example that have had their owners install an RX 480. There is no issue for Apple to fix. Finally, coming back to the IGPU thing. All that matters is that Clover doesn't touch the RX 480 in someway that it only does to the 'boot' (primary) GPU before macOS can get at it. What this means is that as long as Clover is told that a GPU other than the RX 480 is the 'boot display', then it won't do whatever it is that its doing that causes Polaris cards to crash upon initialization of the card by macOS's X4100 kext. As far as I know, most BIOSes will make any GPU the primary GPU if there is only one. So all you need is 2 GPUs, and to force the one that ISN'T the RX 480 to be the primary/boot gpu, or in other words, the gpu the post screen and clover menu/EFI video is sent to. The IGPU is a convenient, already-present second GPU for some people. For those without, they simply need a second GPU at all. It doesn't matter what. In my case, I have tried this piece of {censored} and as long as it is primary, the RX 480 works great. It also works with what I have installed right now as primary, a GTX 960. It also works with an old Radeon HD 6870. It doesn't matter how, as long as the effect is the same. That effect is preventing the RX 480 being used as primary. Using an IGPU is one of many possible ways of achieving this, but there is nothing specific to an IGPU involved, only that it is a GPU. A gpu that is not a Polaris GPU, but is primary. Now, I've been digging through the Clover and EDK code, and frankly, I am at a total loss so far. I think it is safe to say that it is something specific and only done to the boot GPU by Clover, as there is no problem with OS X using the GPU otherwise (on a real mac or hackintosh) that leaves some register in a state that the X4100 kext does not expect and would never occur normally, so it panics. And Apple won't fix it because there is no problem to fix - except with Clover. Just to be clear, I am in no way 'blaming' Clover or slice or any other of the developers. That they include code for GPUs before they are available and then it works at all, even with workarounds, is an amazing feat and requires a great deal of skill and intimate knowledge of both hardware in general as well as how macOS uses it specifically. But, I am just saying, that is where the solution will be found. Considering no one has even bothered to create a ticket on Clover's source forge page though, it is not going to be soon. I'll open a ticket after this post, though considering how old this thread is, I don't understand why it hasn't already been done. Oh, and doing anything with DSDT is a dead end. Clover is what loads the ACPI tables then hands them off to macOS, it also has to talk to the hardware, set registers, query device IDs, map memoryio base locations, etc. before ever loading any ACPI tables, so changes to DSDT etc. will not have any effect. Beyond that, this is a case of Clover doing something it ought not to on Polaris GPUs, or perhaps NOT doing something it needs to after its done something else that it does only to the boot gpu on polaris CPUs. We know this because there is no problem if it is not the boot gpu. It already works. What doesn't work is initialization by the driver if clover has already been using it. Oh, right, proofs, working even with the old crappy GeForce card (comma is my bad a typo that I haven't bothered to fix lol. I am using an SSDT hot patch to inject the ID for an RX 460 so the kext matches unmodified, as well as disable the other slot devices that could match instead...but I digress. It doesn't matter if it is done this way, or with the native ID and patched plist, and looking at the clover code, there is no meaingful difference in how it treats polaris 10 vs 11 anyway): Also, the compute performance is a little disappointing, but certainly much faster than the GTX 960. The performance under windows is almost 130,000, but this is to be expected. Apple's OpenCL implementation has always been a {censored} show and probably isn't going to get any better soon or ever. I also have mine underclocked, I'll try another full power bench later (I was making sure my thermals were adequate). I don't expect to hit more than 100,000 however under OS X.
  8. Hmm... I usually see that error when the kernel or something else critical is suffering form data corruption. Aside from trying to boot into single user mode (-s), the only advice I can give you is to try recopying everything. This is a long shot, but I've accidentally booted from my hard drive thinking I was booting from my thumb drive a couple times. If you have chameleon installed on both and don't always stick to the same boot device priorities, it's definitely a possibility. Since 10.8 requires chameleon r1820 or greater, it might KP like this when an older version of chameleon is messing with a large cat it hasn't been trained for.
×