Да, помню, как пробовал решить Вашу задачу, будучи уверенным, что это не так сложно, но на втором часу понял, что тут есть какой-то нетривиальный приём, который не сильно известен, но работает.
Решение однозначно не является тривиальным и это решение однозначно не то, что первым придёт в голову.
То, что такое решение есть вообще и то, что оно было найдено — очень круто.
Покопался на различных форумах и после продолжительного гуглинга наткнулся на такой пост касаемо управления питанием дискретных адаптеров.
Вкратце: карты с архитектурой Turing используют более стандартные методы управления питанием, в то время как в Pre-Turing-картах используются DSM (device specific method), который и дёргается модулем bbswitch, чтобы обесточить карту. В частности, в этом посте описано.
На данный момент имеем ситуацию, когда для Nvidia PRIME требуются загруженные модули ядра nvidia и, пока они загружены — Pre-Turing-карты остаются включёнными, а DPM большой погоды тут не играет (в частности, этот метод позволяет свести энергопотребление карты к минимум, но не до нуля).
Остаётся ждать полноценного внедрения в модули nvidia возможности дёргать их же DSM-вызовы для полноценного энергосбережения.
Кстати, если бы Вы об этом не сказали — я бы и не вспомнил.
Прелесть bumblebee в том, что он полностью выгружает модули ядра, после чего bbswitch полностью отключает питание дискретной карты, и наоборот.
В нативном nvidia-prime питание дискретной карты управляется линуксовым DPM (при условии, если правильно настроен TLP/laptop-mode-tools). Тем не менее, модули ядра (nvidia, nvidia-drm etc) остаются загруженными, а к видяхе можно обратиться в любой момент.
К сожалению, после серии экспериментов я пришёл к выводу, что нативный Nvidia PRIME + DPM не обеспечивает такое энергосбережение, как bumblebee + bbswitch.
Новость вышла тихо, но событие однозначно громкое.
Я, как пользователь ноутбука с Intel + NVIDIA, который всё время пользовался Bumblebee, испытывал с ним проблемы, начиная от того, что для запуска чего-либо на дискретной карте запускается отдельный Xorg и заканчивая детскими болячками, вроде тиринга и input lag, причём получается избавиться либо от одного, либо от другого.
Прочитал новость поподробнее и начал копаться в своём Arch Linux:
1. Удалил всё, что связано с Bumblebee: bbswitch, nvidia-xrun, primus и т.д;
2. Настроил TLP, убрав PCI-устройство с чёрного списка, после чего его питание начало управляться динамически, DPM;
3. Скачал слепок репозитория отсюда, скомпилировал, установил.
4. Подправил xorg.conf (пример взял с этой статьи). Так как по некоторым причинам я не использую драйвер modesetting, я изменил в конфигурационном файле на intel (xf86-video-intel);
5. Перезапустил X-сессию и добавил в ~/.zshrc такую «гениальную» строку:
alias optirun='__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia'
6. Проверил.
В результате я получил отсутствие тиринга, input lag'а и даже небольшое повышение FPS в 3D-приложениях.
Остаётся ждать релиза Xorg с патчами в официальных репозиториях.
Статья начиналась по-настоящему интересно, но, увидев внезапное окончание без должной развязки, взгрустнул.
Не знаю точно, почему, но вспомнился мем про «Что будет, если бросить лом в унитаз»: вопрос есть, но ответы на него, скажем, не столь очевидны.
Нет, сомневаться в том, что на MCU реально можно запустить «десктопное» ПО и даже целую ОС можно — прецеденты были. Другой вопрос в том, какова цена запуска «жирного» «десктопного» ПО на микроконтроллера, которые для этого не очень-то и предназначены, в практической плоскости.
Edit:
Почесал голову и понял, что задача сабжа — Embox — реализовать слой абстракции, пригодного для коммуникации прикладного ПО на микроконтроллерах с отличной от таковых в ПК, в классическом понимании; задача статьи — написать, что такой инструмент существует, но лично я ожидал развязку в виде примера компиляции какой-то утилиты и последующего её запуска на микроконтроллере.
Я, будучи поменьше, был заинтересован разве что шкалой тонов, о которой рассказывали в контексте наркомании и склонности к ней. Признаюсь, что сама концепция шкалы тонов и того, в каком тоне находится человек, была мне интереса и правдоподобна. И только потом узнал, что это относится к саентологии и тут всё не так уж и чисто. А тут случайно наткнулся на статью и вспомнил. Надо же, мир тесен...
На самом деле дельный совет.
Конкретную задачу, честно говоря, я не преследовал, только экспериментирование и сравнение кодеков. Судя по всему, в текущем виде публикация готова и стоит подумать, о чём ещё интересном стоит написать. В любом случае, пока писал и пока читал комментарии — узнал много нового; оно того стоило. :)
И снова спасибо.
Посмотрел видео. Спасибо, очень интересный материал. И в публикацию, кстати, внёс поправки.
У меня есть вопросы к Вам (да и ко всем, кто ознакомился с материалом).
Публикация затрагивает только кодирование голоса. При кодировании музыки я получил не менее интересные результаты. Стоит ли расширить публикацию нюансами кодирования музыки? Стоит ли дополнить её семплами, закодированными при помощи, к примеру, того же neroAacEnc, а может даже дополнить её спектрограммами? Стоит ли добавить картинку и кратко дополнить применение MDCT, чтобы у читателя имелось представление, для чего это необходимо (переход из амплитудной плоскости в частотную)?
Впрочем, есть подозрение, что эти дополнения будут уже не так интересны читателям.
Голосовалку решил не ставить.
Я не разобрался в подобных тонкостях и рад, что Вы указали на это. Я помню, что вещи, которые происходят в таких кодеках как MPEG Layer I/II и Musepack, происходят также и в SBC, используемый по умолчанию в Bluetooth-профиле A2DP, верно? Также я понял, что MDCT в большинстве случаев используется только потому, что с результатами преобразования данным подходом проще работать с точки зрения реализации алгоритмов.
Я поправлю в статье нюанс со вторым MDCT, чтобы не вводить читателей в заблуждение.
Спасибо, очень подробно и доходчиво описано.
Не уверен, если честно. Я находил статьи на Хабре на эту тему, но конкретные эксперименты мне на глаза не попадались. Я бы с радостью это провёл, но с описанием физики процесса кодирования сигнала codec2 у меня будут большие проблемы — я не математик.
Просто Вы, как и я, перепутали аббревиатуру "VHD" (virtual hard drive) с "VHS" (video home system).
Да, помню, как пробовал решить Вашу задачу, будучи уверенным, что это не так сложно, но на втором часу понял, что тут есть какой-то нетривиальный приём, который не сильно известен, но работает.
Решение однозначно не является тривиальным и это решение однозначно не то, что первым придёт в голову.
То, что такое решение есть вообще и то, что оно было найдено — очень круто.
Спасибо за статью, Дмитрий.
Вкратце: карты с архитектурой Turing используют более стандартные методы управления питанием, в то время как в Pre-Turing-картах используются DSM (device specific method), который и дёргается модулем bbswitch, чтобы обесточить карту. В частности, в этом посте описано.
На данный момент имеем ситуацию, когда для Nvidia PRIME требуются загруженные модули ядра nvidia и, пока они загружены — Pre-Turing-карты остаются включёнными, а DPM большой погоды тут не играет (в частности, этот метод позволяет свести энергопотребление карты к минимум, но не до нуля).
Остаётся ждать полноценного внедрения в модули nvidia возможности дёргать их же DSM-вызовы для полноценного энергосбережения.
Прелесть bumblebee в том, что он полностью выгружает модули ядра, после чего bbswitch полностью отключает питание дискретной карты, и наоборот.
В нативном nvidia-prime питание дискретной карты управляется линуксовым DPM (при условии, если правильно настроен TLP/laptop-mode-tools). Тем не менее, модули ядра (nvidia, nvidia-drm etc) остаются загруженными, а к видяхе можно обратиться в любой момент.
К сожалению, после серии экспериментов я пришёл к выводу, что нативный Nvidia PRIME + DPM не обеспечивает такое энергосбережение, как bumblebee + bbswitch.
Возможно, я что-то недонастроил.
Я, как пользователь ноутбука с Intel + NVIDIA, который всё время пользовался Bumblebee, испытывал с ним проблемы, начиная от того, что для запуска чего-либо на дискретной карте запускается отдельный Xorg и заканчивая детскими болячками, вроде тиринга и input lag, причём получается избавиться либо от одного, либо от другого.
Прочитал новость поподробнее и начал копаться в своём Arch Linux:
1. Удалил всё, что связано с Bumblebee: bbswitch, nvidia-xrun, primus и т.д;
2. Настроил TLP, убрав PCI-устройство с чёрного списка, после чего его питание начало управляться динамически, DPM;
3. Скачал слепок репозитория отсюда, скомпилировал, установил.
4. Подправил xorg.conf (пример взял с этой статьи). Так как по некоторым причинам я не использую драйвер modesetting, я изменил в конфигурационном файле на intel (xf86-video-intel);
5. Перезапустил X-сессию и добавил в ~/.zshrc такую «гениальную» строку:
6. Проверил.
В результате я получил отсутствие тиринга, input lag'а и даже небольшое повышение FPS в 3D-приложениях.
Остаётся ждать релиза Xorg с патчами в официальных репозиториях.
Не знаю точно, почему, но вспомнился мем про «Что будет, если бросить лом в унитаз»: вопрос есть, но ответы на него, скажем, не столь очевидны.
Нет, сомневаться в том, что на MCU реально можно запустить «десктопное» ПО и даже целую ОС можно — прецеденты были. Другой вопрос в том, какова цена запуска «жирного» «десктопного» ПО на микроконтроллера, которые для этого не очень-то и предназначены, в практической плоскости.
Edit:
Почесал голову и понял, что задача сабжа — Embox — реализовать слой абстракции, пригодного для коммуникации прикладного ПО на микроконтроллерах с отличной от таковых в ПК, в классическом понимании; задача статьи — написать, что такой инструмент существует, но лично я ожидал развязку в виде примера компиляции какой-то утилиты и последующего её запуска на микроконтроллере.
Я, будучи поменьше, был заинтересован разве что шкалой тонов, о которой рассказывали в контексте наркомании и склонности к ней. Признаюсь, что сама концепция шкалы тонов и того, в каком тоне находится человек, была мне интереса и правдоподобна. И только потом узнал, что это относится к саентологии и тут всё не так уж и чисто. А тут случайно наткнулся на статью и вспомнил. Надо же, мир тесен...
Конкретную задачу, честно говоря, я не преследовал, только экспериментирование и сравнение кодеков. Судя по всему, в текущем виде публикация готова и стоит подумать, о чём ещё интересном стоит написать. В любом случае, пока писал и пока читал комментарии — узнал много нового; оно того стоило. :)
И снова спасибо.
У меня есть вопросы к Вам (да и ко всем, кто ознакомился с материалом).
Публикация затрагивает только кодирование голоса. При кодировании музыки я получил не менее интересные результаты. Стоит ли расширить публикацию нюансами кодирования музыки? Стоит ли дополнить её семплами, закодированными при помощи, к примеру, того же neroAacEnc, а может даже дополнить её спектрограммами? Стоит ли добавить картинку и кратко дополнить применение MDCT, чтобы у читателя имелось представление, для чего это необходимо (переход из амплитудной плоскости в частотную)?
Впрочем, есть подозрение, что эти дополнения будут уже не так интересны читателям.
Голосовалку решил не ставить.
Я поправлю в статье нюанс со вторым MDCT, чтобы не вводить читателей в заблуждение.
Спасибо, очень подробно и доходчиво описано.