Jump to content

E6540: Can discrete graphics card be disabled?


z1326

Recommended Posts

  • Administrators

What I did was:

1) rename integrated GPU device GFX0 (@0x00020000) to IGPU in DSDT + SSDT-8 + SSDT-9 as per Apple MacBooPro11.x ACPI tables

2) rename discrete GPU device PEG0.PEGP (@00010000) to P0P2.GFX0 in DSDT + SSDT-8 + SSDT-9 as per Apple MacBooPro11.x ACPI tables

 

3) add external methods declarations for SB.PCI0.P0P2.GFX0._ON and SB.PCI0.P0P2.GFX0._OFF at beginning of DSDT

4) add a Scope SB.PCI0.P0P2.GFX0 in DSDT with an _INI Method that just calls _OFF Method (declared in external table SSDT-9)

5) add calls to SB.PCI0.P0P2.GFX0._OFF in _WAK Method

Link to comment
Share on other sites

  • Replies 24
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

  • Administrators

Gave it another shot from your raw table... I just:

1) in SSDT-8:

  • added a call to _OFF in Method _INI of \SB.PCI0.PEG0.PEGP

2) in DSDT:

  • removed incorrect external method _SB.PCI0.RP05.PEGP.EPON in definition block at beginning of table (no such method exists)
  • removed calls to _SB.PCI0.PEG0.PEGP.EPON and _SB.PCI0.RP05.PEGP.EPON in method _WAK
  • added a call to _SB.PCI0.PEG0.PEGP._OFF in method _WAK to disable the discrete GPU on Wake
  • added a call to _SB.PCI0.PEG0.PEGP._ON in method _PTS to enable the discrete GPU on Sleep
  • fixed a few classical issues generating errors at compilation (e.g.: rename device "*pnp0c14" to "PNP0C14")
No renaming of devices this time, just to do quick tests.
 
Give that a try and let us know.
 
Link to comment
Share on other sites

  • Administrators

I've done some further testing on my E6440 and I just cannot reproduce your issue at all. I can't even boot OS X if I revert to standard BIOS table and boot without cache and without proper HD4600 injection. I can clearly see that attempts to load Radeon graphics are made but system then hangs and does not complete boot. It does not really matter whether I add _ON or _OFF to the _INI method for SSDT scope SB.PCI0.PEG0.PEGP...

 

Can you make sure that you inject your HD4600 properly?

  • With Mavericks, you simply need to inject Intel Azul FB #12 or Intel-ig 0x0a260006 (with Chameleon/Enoch, this translate into IntelAzulFB=12 and InjectIntel-ig=0600260a).
  • From Yosemite onwards, you need to load Rehabman's FakePCIID + FakePCIID_Intel_HD_Graphics, inject Intel-ig 0x0a260006 and fake desktop HD4600 id 0x0412.

Thereafter for me, there is simply no visibility of the Radeon dGPU and not a single mention of it in the boot/system log or in SysProfiler.

Link to comment
Share on other sites

  • Administrators

Arf, I forgot one stupid thing!
 
Assuming you already have a file SSDT.aml (for CPU power management settings), the revised SSDT table needs to be renamed SSDT-1.aml for it to be loaded by the bootloader. At least, that's how it works with Chameleon/Enoch: tables are read in the order SSDT /  SSDT-1 / SSDT-2 / SSDT-3, etc. I've verified this in verbose mode.
 
If keeping original SSDT-n.aml name (like SSDT-8.aml or SSDT-9.aml):

E6440:~ admin$ bdmesg
Enoch (2839)
...
...
...
[ ACPI PATCHER ]
Table /Extra/DSDT.aml read and stored at: 2f57000
...
Table /Extra/SSDT.aml read and stored at: 2f69000
ACPI Table not found: SSDT-1.aml
...
DSDT: Old @c8fd31b0,50304943,  New @2f57000,50304943
...
TABLE APIC, TABLE FPDT, TABLE LPIT, TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE HPET, TABLE SSDT, OEM SSDT tables was dropped
TABLE MCFG, TABLE SSDT, OEM SSDT tables was dropped
TABLE ASF!, TABLE SSDT, OEM SSDT tables was dropped

RSDT: Added 1 SSDT table(s)
RSDT: Original checksum 180,  New checksum 62 at 2f6c000
...
Added 1 SSDT table(s) into XSDT

...
ACPI version 2 patching finished
 

If renaming the revised table to SSDT-1.aml:

E6440:~ admin$ bdmesg
Enoch (2839)
...
...
...
[ ACPI PATCHER ]
Table /Extra/DSDT.aml read and stored at: 2f57000
...
Table /Extra/SSDT.aml read and stored at: 2f69000
Table /Extra/SSDT-1.aml read and stored at: 2f6a000
ACPI Table not found: SSDT-2.aml
...
DSDT: Old @c8fd31b0,33373330, New @2f57000,33373330
...
TABLE APIC, TABLE FPDT, TABLE LPIT, TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE SSDT, OEM SSDT tables was dropped
TABLE HPET, TABLE SSDT, OEM SSDT tables was dropped
TABLE MCFG, TABLE SSDT, OEM SSDT tables was dropped
TABLE ASF!, TABLE SSDT, OEM SSDT tables was dropped

RSDT: Added 2 SSDT table(s)
RSDT: Original checksum 180, New checksum 130 at 2f6e000
...
Added 2 SSDT table(s) into XSDT

...
ACPI version 2 patching finished
Link to comment
Share on other sites

  • Administrators

Hmm, I've made additional tests and, since my dGPU appears turned off at boot time, I tried to turn it on through SSDT or DSDT edits. I've not managed to reach success yet.

 

However, this reminded me that, many moons ago, I had noticed that HWMonitor never displayed any info about GPU at startup, only after wake. Basically, I would get this:

       At startup and until sleep                              After wake

HWMonitor_Startup.jpg   HWMonitor_Wake.jpg

 

Now, if you look at the DSDT code for the _WAK method, you'll notice the following section:

       If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
       {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON))
            {
                \_SB.PCI0.PEG0.PEGP.EPON ()
            }

            If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON))
            {
                \_SB.PCI0.RP05.PEGP.EPON ()
            }
        }

`

To me this code is partially erroneous in the sense that there is no PEGP device under RP05 in any ACPI table, however the discrete GPU is definitely handled by PEGP under PEG0.
 
Check what you get in HWMonitor at startup. If no GPU info appears, I believe your dGPU is off. If it appears, we'll have to find the right code to turn it off. If, like me, your dGPU appears turned on only after wake, apply the following DSDT patch:
  • edit the SSDT table where method EPON is defined and create a new EPOF method (it did not exist in my SSDT-xx table).
  • EPON method only sets ONOF parameter to 1 (true) so you can simply copy/paste the EPON code in a new EPOF method where you set ONOF parameter to 0 (false).
  • in the above DSDT _WAK code, you can then replace the call to EPON by a call to EPOF instead. In the relevant SSDT table, you may notice that the ONOF parameter is used in SGON and SGOF methods that turn the dGPU on or off.
  • although it would appear like the obvious thing to do, removing the above _WAK code is simply ineffective.
 
In a nutshell:
  • in your relevant SSDT-xx table, add this after EPON method:
        Method (EPOF, 0, Serialized)
        {
            Store (Zero, ONOF)
            Return (Zero)
        }
  • in your DSDT, change the _WAK code to:
       If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
       {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPOF))        // Replace EPON by EPOF
            {
                \_SB.PCI0.PEG0.PEGP.EPOF ()                  // Call to EPOF to turn off dGPU
            }

// Comment out or remove those useless 4 lines below
// -------------------------------------------------
//           If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON))
//            {
//                \_SB.PCI0.RP05.PEGP.EPON ()
//            }

       }      // <----- Don't remove or comment out that closing bracket!

`

I think that should sort you out if dGPU is indeed turned off at startup and only activated after wake.
 
Meantime, I'll keep trying to find the right code to really turn on or off the dGPU at system startup.
Link to comment
Share on other sites


×
×
  • Create New...