Всем доброго времени господа ))
Может кому пригодится данная манипуляция.
Что необходимо сделать что-бы физически отключить дискретную графику, и после включения картинка рисовалась с встроенной в процессор hd530 630...:
Первое, снимаем R9800 тем самым обесточиваем U9800 он же gmux, это необходимо для того что-бы не запускалось питание дискретки. Либо замыкаем на землю EG_RAIL4_EN, короче без разницы, либо то либо то.
Далее, замыкаем на землю LCD_MUX_SEL, удобно на R9853, это нужно что-бы заставить коммутатор U9850 выводить EDP сигналы с процовой графики.
Ну и последнее, подаем PP3V3_S0 на BKLT_PWM_MLB2TCON (R9828), EDP_PANEL_PWR_EN (R9826), EDP_BKLT_EN (R9827).

Огромное спасибо за то, что нашли время и написали данную инструкцию.
Вот только речь шла о проблемах интегрированного видео и отключении iGPU. То есть получается UMA наоборот.
Программно решается путём подмены идентификатора и загрузится не с любым. Например, для HD630 (591B:8086) это будет 5918
для чего в DeviceProperties добавляются строки
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
<dict>
<key>AAPL,ig-platform-id</key>
<data>
AAAYWQ==
</data>
<key>device-id</key>
<data>
GFmGgA==
</data>
<key>model</key>
<string>Intel HD Graphics 630</string>
</dict>
</dict>
В итоге выглядеть это будет так:

Может, я не правильно что-то понял, но по-моему в той теме разговор шёл в таком ключе: дефекты интегрированной графики и их необычное проявление. У автора не было изображения пр подключенной батарее, в моём случае интегрированная падала испугавшись HEVC или heic.

Ну не знаю, прочел тему еще раз вроде реч идет конкретно об аппаратном переводе в uma.

d-pal
Ну и не парьтесь, значит я ошибся.
То действие подразумевает наоборот - отключение интегрированной графики и использование только дискретной, что сулит не только потерю управления яркостью и выходом из сна, а так же придётся сказать "прощай" Intel Quick Sync. Можно, конечно прописать декодеры H.264 и HEVC для Baffin вручную, чего впрочем не потерпит ни одна современная ОС. Запустить же энкодер вообще способов не существует.
Так, баловство только.

Вы говорите замыкаем на землю R9853. Вы не ошиблись ? Он же так замкнут резистором на 100K

Если не отключать питание U9800 удаляя R9800, то на LCD_MUX_SEL будет высокий уровень, дальше думаю понимаете что будет..
Если отключать питание то возможно и не нужно R9853 замыкать, не проверял.
---------- Добавлено спустя 1 минуту 31 секунду: ----------

Корректнее будет сказать подтянут как по мне )

Так и не смог разобраться с этой странной ситуацией.
Загрузка стопорится на 3 минуты. Если выждать это время, ОС загрузится. Не открываются heic и не проигрываются hevc.
Вместо стандартной картинки на рабочем столе - чёрный фон. Вместо видео hevc (Apple TV, App Store) - зелёное окно со звуком.

Любые 3D тесты проходит. При попытке подсунуть hevc или heic очень надолго подвисает в сопровождении воя вентиляторов. Температура процессора под 90 градусов.
Если загрузиться с аргументом -igfxvesa (это аргумент WEG, соответственно нужен он сам и Lilu.kext) - загрузится быстро.
Если скомандовать defaults write com.apple.AppleGVA gvaForceAMDAVCDecode -boolean yes - будут использоваться декодеры дискретной карты.
При этом регулируется яркость, нормально работает сон и выход из него.
В принципе, можно пользоваться и так. Энкодер и Quick Sync, естественно, завести уже не удастся.
Но чисто ради спортивного интереса всё же хочется понять - что это?
Разве декодер может сломаться? HDCP? Проблема в gMux?

хороший способ для проверки убитого видео с 2012 года

Ну да, 13, 14, 15 годы с дискреткой тоже самое.

Да неужели? В А1707 есть R9853, что очень удобно, но в А1398 он отсутствует и LCD_MUX_SEL на поверхность не выходит нигде.
Может, конечно, я ошибаюсь. Точнее, очень надеюсь на то, что я ошибаюсь :)
P.S. И я был не прав. Извините меня :(

Ребят, а на A2141 (820-01700-A) возможна такая переделка для диагностики?

На всех возможна.2141 я переводил в УМА с регулировкой яркости

При использовании программного способа яркость у А1707/А1990 тоже регулируется. На более новых не пробовал.
Причём, регулируется яркость как при отключении dGPU, так и отключении iGPU.

Программный способ слетает каждый раз при сбросе NVRAM и при обновлении а аппаратный нет. И как программно отключить если нет изо??

Это аргументы WEG, куда они могут слететь.

Если используют методику отключения при помощи перепрошивки EFI - то такой "грех" присутствует.

Gmux насколько я помню шьётся только Lattice, а значит только платформы Sandy Bridge. Но для этих платформ и программный метод отточен. Там и регулировка яркости исправляется программно. Но позже устанавливается Renesas и по-моему он не шьётся. Нечем. Или я ошибаюсь?
Но кажется вы меня не понимаете. Вы создаёте загрузчик (Open Core или Cover - кто чем привык пользоваться). WEG не работает без Lilu.kext, поэтому они загружаются оба, причём Lilu должен загружаться первым.
Не важно - сбрасываете вы NVRAM или что ещё, загрузчик загрузит аргументы, которые вы прописали при первом же запуске. Нужен вам спуфинг SMBIOS или нет это уж вам решать. Загрузчик может быть "пустой".
Речь идёт о диагностических целях и не только. Не всегда оно имеет смысл.
Например, у вас есть А1398 с еле живой Nvidia. Если загрузиться с аргументом ngfxgl=1 она будет в системе, но поскольку она не обладает свойствами Metal теперь, она и не используется системой. Но присутствует. Как бонус - регулируется яркость и есть пробуждение из сна.
Аргумент -wegnoegpu полностью удалит ускоритель из системы. Яркость уже регулироваться не будет. Аргумент системы nv_disable=1 оставит ускоритель в системе. Регулировки яркости тоже не будет. Но для этого аргумента и WEG не нужен, поскольку это аргумент системы.
И он будет сброшен при очистке NVRAM.
В последних двух случаях программный метод не даёт никакой выгоды. Чисто для диагностики может быть использован. К тому же температура в среднем на десять градусов выше будет.
При программном методе остаётся некий шанс, против того, что вы убрали сразу dGPU и получили инвалид, которым довольно проблематично пользоваться.
Платформа А1707 работает иначе. И возможности шире. При любом раскладе нужно избегать ситуации, когда ускоритель полностью отсутствует в системе или для него не загружен kext. И здесь игра ведётся на той же стороне - устройство должно быть, но без свойств Metal.
WEG позволяет это сделать. И никуда это не улетит, если только вы не отформатируете диск полностью.
Как бонус владелец или клиент приобретает возможность установить ОС, которая официально не устанавливается на этот компьютер.
Не понимаю, кому от этого плохо? Речь о деньгах? У всех в прайсе есть программный ремонт и установка macOS.

Уже несколько лет отключаю аппаратно на всех моделях вплоть до A2141 начиная с 2011года пока только 1990 не попадалась. На 1707 проблема пока не вывел яркость ,на остальных вывел.На 2141 приходится использовать core для правильной регулировки на остальных регулируется по умолчанию но и на 2141 сразу яркость максимальная а после патча спокойно регулируется в штатном режиме.В основном попадают совсем без изображения и выходят полностью функциональные можно переставлять, апдейтить ось и делать что хочешь просто как модели без видео .Считаю что все эти программные танцы с бубном ерунда! Всегда найдется идиот который нажмет нужные кнопки и останется без изображения , а у меня всегда будет изо и в большинстве случаев для регулировки яркости ничего делать не надо .

Спасибо что разъяснили, теперь все получилось! А как сделать что бы подсветка работала?

Пожалуйста ))
Если вы имеете виду регулировку яркости, не вникал, делал это в целях диагностики, и не считаю это полноценным ремонтом (ну в смысле кастрацию ноута ). Ну а так, если это вам нужно, разбирайтесь...) Сделаете, расскажете, за одно и тему дополните..)))

Спасибо,
Есть такой аппарат: при загрузке, переключение граф. процессора гаснет и стартует по новой.
В safe mode работает стабильно.
Менялись: cpu, gpu. Ошибка осталось.
Только VRAM не менял..
Можно у А2141 VRAM проверить на наличие ошибок?

или, как будет отключение дискретной у А2141?
Там другие сигналы чем у А1707.