Гибридная архитектура Intel уже готова для Linux?

Она ни для чего не готова.

Все нормально, бери

Чтобы не страдать от завышенных ожиданий, бери амд.

По гибридной архитектуре дела сейчас такие.

1. ITD (Intel Thread Director) - под онтопиком не работает и видимо не будет. Последние экспериментальные патчи были на ядре 6.4 ( но не в основной ветке а в гитхабе интела). Разарботка похоже заброшена навсегда.

2. Новая разработка построена на Energy Aware Scheduler, в мейнлайн ядро еще не пришла. Но для нее требуется отключение гипертрединга - причем на уровне биоса что не всегда возможно. Пытался отключать на метеорлейке после бута - не работет, все начинает глючить и сыпаться. То есть скорее всего она будет работать с лунарлейка и новее где этот гребаный гипертрединг отсутствует как класс из коробки.

3. Для несчастных обладателей всего старого хлама он 12 поколения до метеорлейка придется довольствоваться дефолтным поведением - то есть гребанный скедъюлер написанный геймерами и для геймеров (других объяснений не вижу) кидает все задачи на тяжелые ядра (прощай батарея). Хотя говорят когда-то давно было наоборот но геймеры подняли вселенскую вонь и для них сделали вот так.

4. Утешительный приз - интел выпустил демон intel-lpmd - демон который в зависимости от загрузки системы «отключает» ядра - он их не оффлайнит, а просто говорит скедъюлеру - вот эти ядра не используй и мигрируй все таски нв вот эти. Он там в какой-то очень ранней версии но работает, правда в базовых установках дистров его скорее всего не будет.

Так что в принципе использовать можно - но нужно собрать и настроить intel-lpmd. В противном случае будет просто горячая интеловская печка.

ЧТо до версий ядра - то LTS норм. Так как вся логика реализована в демоне а не в ядре. И да - демон тоже понятия не имеет какое ядро какое. Ему в конфиге надо будет прописать номера ядер которые надо включать-выключать при определенной утилизации.

Судя по моим экспериментам поддержка максимально примитивная и сводится к тому, что P ядра используются в первую очередь. Ни о какой энергоэффективности уровня мака речь не идет. Впрочем если сравнивать со старыми процессорами, то минусов я тоже не найду, лишь бы P ядер было не меньше, чем ядер в старом сравниваемом процессоре. Так что покупай.

intel-lpmd последний коммит 2 месяца назад. Не выглядит похожим на живой проект.

Ну он во первых тупо работает - если написать конфиг.

И во вторых - это единственное что есть на данный момент и единственное что в перспективе доступно обладателям 12-15 поколений процессоров.

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

энергоэффективности уровня мака

Энергоэффективность мака лежит в мак-ос - то есть у нас монокультура в которой ОС затачиается под определенный класс приложений (всякий дизайн-мультимедиа и прочий креатив) , а железо затачивается под ОС подгоняя эффективные хардверные помогайки вместо процессоров общего назначения.

Под линуксом увы так не получается, и под вендой тоже. Тут недавно один блоггер тестировал Honor Vagic Book Art 14 - две версии. На интел метеорлейк ( которая у меня сейчас ) и на снапдраконе. Полный заряд и ютубчик до высадки батареи в ноль. Интел сдох в ноль, у снапа осталось 24% батареи. То есть да - арм вроде как энергоэффективнее интела но там не идет речи о том что вот на интеле 6 часов а на арме 18. Разница 25% - если сравнивать один и тот же ноут с одной и той же ОС, одинаковым экраном и тд.

Честно признаться я не совсем согласен про всё это затачивание. Да, некоторое затачивание есть, даже есть специальный режим в процессоре для ускорения JavaScript и для ускорения эмуляции amd64. Но в общем и целом это просто предоставление хардварных блоков для популярных алгоритмов, вроде ускорения шифрования, (де)кодирования и тд. Всё это и на винде и на линуксе есть. Вот то, что гугль хром до сих пор из коробки на линуксе не использует аппаратное (де)кодирование, это грустно, но это уже конкрено косяк линукса с его зоопарком библиотек и драйверов (и маргинальность, не позволяющая разработчикам гугльхрома просто протестировать все возможные сочетания всего зоопарка и написать код под все варианты, как они это делают с виндой), а не превосходство макоси.

Т.е. да, с одной стороны в макоси всё лучше, с другой стороны мне всё время кажется, что в линуксе вот-вот и стабилизируется всё и всё станет хорошо.

Если вернуться про обсуждение P/E ядер, я уже писал в какой-то теме, что нужен просто API в линуксе, позволяющий потоку выдавать подсказку планировщику о том, что его производительность не важна. Вообще-то это уже есть в виде nice, но, возможно, нужно другое API… Или просто доработать планировщик и при nice выше, скажем, 9, класть поток только на E-ядра. Т.е. программы-то может люди и хотели бы дописать, но как их дописывать? Парсить cpuinfo и прибивать поток к E-ядрам? В каждой программе? Вынести это в libcpupe? В общем вроде как технически можно… Но лучше бы это всё сделать в виде ядерного API, чтобы программа просто сказала - что этот поток делает не важную задачу и её можно делать максимально энергоэффективно, не грузя P-ядра этой ерундой. Ну и потихоньку доработать те программы, где это имеет смысл, всякие там индексаторы и прочее фоновое.

не позволяющая разработчикам гугльхрома просто протестировать все возможные сочетания всего зоопарка и написать код под все варианты

Мне такие заявления удивительны. Хорошо, дистрибутивов Линукса много. Почему это не работает на текущей и лтс Убунте? Хотя бы только на лтс Убунте? Или сгорел сарай, гори и хата? Не жили богато – неча и начинать? Это просто нелепая отговорка. Малая доля рынка, им просто не хочется это делать.

p.s. Пользуюсь, если что, Федорой.

я в свое время копался в багах по энергоэффективности аппаратного декодирования видео на амд. Ну как тестер в основном конечно.

И там вот какая штука - аппаратный декодер за три милливатта выдает тебе изображение в некий внутренний буфер. Это у амд. У интела можно даже за еще три милливатта задать декодеру колорпспейс и масштабирование - и все. Но тебе надо этот внутренний буфер вывести в окошке броузера - ну ютуб представляешь. Так вот в линуксе то делается шейдерами 3д ускорителя. И толку от этих милливаттов декодера уже нет ибо у тебя включается 3Д движок а он жрет как слон. Как это делается в маке? Да вот так - броузер делает окошко в которое напрямую прямо в экранный буфер декодирует аппаратный декодер видео. Ни один 3д блок видеокарты при этом не активируется. Венда делает примерно так же.

И вот именно на этих костылях все и вылезает - то что на линуксе ютуб сожрет твою батарею за 5 часов, на венде за 10 а на маке - за 12 с половиной. И это только частный юзкейс, но их масса.

Мне такие заявления удивительны. Хорошо, дистрибутивов Линукса много. Почему это не работает на текущей и лтс Убунте? Хотя бы только на лтс Убунте? Или сгорел сарай, гори и хата? Не жили богато – неча и начинать? Это просто нелепая отговорка. Малая доля рынка, им просто не хочется это делать.

А почему это должно работать на лтс убунте? Почему не на RHEL? Почему не на федоре? Почему не на астра линукс, простите?

«Не хочется» это не аргумент для коммерческой компании. На самом деле я думаю, что даже текущая поддержка линукса это из разряда «очень хочется».

Ну и LTS убунта, то бишь зафиксированный набор версий библиотек, это только одна грань многообразия. Ещё есть многообразие железа, главным образом видеокарт.

А так - убунте никто не запрещает протестировать совместимость и проставить флаги. Лично у меня на синкпаде с арчем всё работает, я проставил флаги, вроде работает. Но тот факт, что эти флаги не включаются по дефолту, говорит, что я скорей всего исключение, а не правило.

А почему это должно работать на лтс убунте?

Потому что это самый распространенный дистрибутив Линукса.

На RHEL тоже хотелось бы, но софт там слишком старый, может не все поддерживать.

Почему не на федоре?

На Федоре тоже крайне желательно.

Поинт в том, что разнообразие дистрибутивов Линукса – плохая отговорка. Сделайте хотя бы для самого популярного.

Ещё есть многообразие железа, главным образом видеокарт.

Производителя всего три. И их железа не так чтобы слишком быстро меняется. Я не думаю, что для каждой следующей видеокарты надо много чего-то переписывать.

Да вот так - броузер делает окошко в которое напрямую прямо в экранный буфер декодирует аппаратный декодер видео. Ни один 3д блок видеокарты при этом не активируется. Венда делает примерно так же.

Не понял, как это устроено. Там же элементы UI поверх видеопотока еще надо рисовать. Как они это делают без шейдеров?

Фишка с выводом видео отдельным костылём мимо оконной системы во фреймбуфер была вроде в древних виндах, но потом не знаю, как и куда она эволюционировала.

AcceleratedVideoDecodeLinuxZeroCopyGL это не оно, случайно?

Там же элементы UI поверх видеопотока еще надо рисовать.

Их же надо рисовать только при необходимости, они не постоянно отображаются.

Нет. Линукс этого не умеет в принципе. Как я понимаю это удаляет один шаг из шейдера но не устраняет шейдеры в принципе.

Тут же задача чтобы декодер декодировал прямо в экранный буфер а не в композитор.

А нужно то что делает mpv с настройкой dmabuf-wayland - но mpv это умеет только в полный экран.

элементы ui по большей части статичны, а видеопоток надо процессить каждый кадр.

Но да - если ты хочешь там какието дебильные эффекты визуализации вроде тех что любят пихать в аудиоплееры то сам себе злобный буратин, тогда и мак не спасет батарею.

Вообще-то на винде многим играм чтобы они задействовали большие ядра требуется особый пинок от интеловской утилиты, в которой они делают различные пассы чтобы игры все же заработали как надо. А хуже всего то что некоторые выяснили что отзывчивость винды на малых ядрах ниже и некоторые даже переходили на предыдущее поколение процессоров чтобы у них окна быстрее открывались, а видеокартами уже кодируют видео. Так что на стационарном ПК ситуация в линуксе даже лучше, если сделать андервольт. Другое дело что для мобильных процессоров это может быть не вариант и там все зашито из коробки. И вот так выглядит потребление процессора с открытым лором.

core:             1.432 W
package-0:        2.910 W
uncore:           0.010 W


И вот так при воспроизведении 4К видео с тытуба по показаниям intel-undervolt measure

core:             1.333 W
package-0:        4.122 W
uncore:           1.209 W

Настолько готово, что лучше взять АМД.

так то на венде. А на линуксе увы все наоборот.

Чтобы эффективно использовать архитектуру надо чтобы система знала какие приложения где запускать. Каким-нибудь сетевым службам или мп3 плееру и LP ядра достаточно, а под игрушку надо выделять P. Но тут проблема - приложений полно, причем бинарных и древних и даже если сейчас выкатить API как приложению запрашивать ядра - всеравно останется вагон приложений про это не знающих. Это вам не мак где все приложения быстро перестраиваются под новую архитекутуру.

А тут получается два подхода. Либо мы сначала кидаем приложение на легкое ядро и смотрим - норм или ему маловато (загрузило на 90-100% или нет). Если маловато - мигрируем на P. Это то как работает венда сейчас. Либо мы сначала кидаем на P - а там если нагрузка для P маловата мигрируем на E. Это то что было в венде изначально - но при этом батарея высаживалась в ноль не успев отойти на метр от розетки зато геймеры были счастливы. Но в венде батарейная партия победила - а грустные геймеры стали с радостью отдавать конское бабло за процессор с тупо отключенными Е-ядрами.

А в линуксе все изначально хуже. Интел никакой поддержки своих железок не предложил. Пили-пилили не допилили и как в анекдоте - ну не шмогла я. По итогу скедьюлер работает дубово - смотрит на каком ядре больше свободное capacity и туда кидает задачу. Capacity в P ядрах больше чем в E- даже если P ядра частично заняты то всеравно свободное Capacity там больше чем в протсаивающих E - так что линуксовый скедьлер будет кидать задачи на P ядра пока не забьет их под завязку и тогда начнет расчехлять E. Геймеры счастливы - батарея на 2 часа при заявленных 13.

Что интел разрабатывает сейчас - просто пытается использовать код для ARM. В арм есть домены процессорных ядер и энергетические политики - то есть помимо свободной капасити еще и учитывается сколько ватт сожрет выполнение и задача кидается не туда где капасити больше а туда где выполнение задачи сожрет меньше ватт. Для этого во первых нужен schedutil говернер который управляет частотой ядер по команде шедьюлера, а во вторых эта вся штука не умеет обсчитывать гипертрединг. Потому как гипертрединг эмулирует 2 логических ядра на 1 физическом с непредсказуемым разделением ресурсов. Дерьмище это на новых процессорах наконец то отключено - так что будет работать норм (надеюсь ) когда прилетит в ядро (думаю не раньше 6.14). То есть начиная с лунарлейка и с переходом на свежее ядро интел будет работать с разными ядрами примерно как арм. Ну и амд примерно также - они как я понимаю тоже мутят архитектуру с P и E ядрами.

Обладателям старых интелов это увы не поможет из-за гипертрединга который нельзя выключить ( в большинстве ноутбучных биосов ) - хотя возможно интел и выкатит патчи отключающие бяку под маской секьюрити. Но врядли - народец вскормленный маркетинговой соской завопит как так , я платил за 20 ядер а теперь у меня 16 - а ну верните 4 взад - так что скорее всего это не случится и единственный способ это кпить новый ноут.

Ну а что до десктопов - то я до сих пор н е понимаю нахухуа там вообще какие-то кластеры разных ядер если нет батарейки и охлад ставь хоть с жидким азотом. Еще когда были монокристалльные чипы там технологически была причина - один и тот же кристалл и туда и сюда. Теперь же с переходом на чиплеты - в десктопе и серверах вообще никаких е-ядер не нужно…

Это вам не мак где все приложения быстро перестраиваются под новую архитекутуру.

Нет, не все. Там всё просто: кто не адаптировал приложение — добро пожаловать на свалку истории. Время на адаптацию дают, впрочем (в отличие от дистрибутивов Linux).

Ни о какой энергоэффективности уровня мака речь не идет. Впрочем если сравнивать со старыми процессорами, то минусов я тоже не найду, лишь бы P ядер было не меньше, чем ядер в старом сравниваемом процессоре.

Т.е. старый в этом плане ничуть не лучше, чем новый? Просто в новом недопилено то, что могло сделать его лучше (как программно сделано на винде)?

Настолько готово, что лучше взять АМД.

Да я бы с радостью, но выбор только из этих двух, к сожалению.

Обладателям старых интелов это увы не поможет из-за гипертрединга который нельзя выключить

Ядру же можно передать параметр nosmt, при этом ядра гипертрединговые ядра становятся offline (по показаниям htop).

Производителя всего три. И их железа не так чтобы слишком быстро меняется.

На самом деле их больше. Три - на x86 архитектуре - но тут в общем-то да, все верно.

Но вот насчет не слишком быстро - не соглашусь в корне. Оно не слишком быстро пока интел уверял всех что быстрая встройка нереализуема поэтому жричодали то есть древний тормознутый HD а если нужна скорость покупай нвидию.

Но потом амд выкатила мобильную вегу - и гонка встроек началась. следом за гонкой встроек понеслась гонка ноутбучных дискреток ибо смысла в старых смешных пукалках не дотягивающих в производительности до амд-шной встройки стало чуть меньше чем ноль. И меняется там все быстро - но нам это не сильно заметно стало ибо производители сейчас начинают ввыкатывать измеения драйверов задолго до релиза железа для которых оно предназначено. Отсюда и иллюзия - ага, вот у меня новая видюха а драйвер искать не пришлось все завелось из коробки - да там нет никаких изменений старый драйвер все поддерживает.

насколько я понял это верно только для древних ядер - а в новых это заменено на sysfs интерфейс который просто оффлайнит сиблингов но это можно сделать только после загрузки в юзерспейс. Они видны в htop - но как offline. Оно все бы ничего - но ломает suspend-hibernate потмоу как при просыпании эти сиблинги снова активируются биосом и успевают нагадить прежде чем ядро восстановит состояние nosmt. Так что у меня с этим пока ничего хорошего не получилось. Возможно интел как-то доработает это все хозяйство так что ядро начнет при активации EAS само отключать SMT в процессоре. Но пока это не работает, а учитывая нынешние финансовые проблемы синих не стоит ожидать инвестиций в поддержку старых провальных продуктов.

Скорее всего про хлам 12-15 Gen предпочтут поскорее забыть слив остаток стока санкцонным китайцам и россиянам и сосредоточатся на 2хх серии и последующих с улучшенными показателями энергоэффективности.

Так а что за выбор то?

Так а что за выбор то?

Только из этих двух вариантов:

LENOVO THINKPAD P1 GEN 4 i9-11950H 32GB RAM 1TB SSD RTX3080 16GB 4K

vs

HP ZBook Studio G10 i9-13900H 32GB RAM 2TB SSD RTX4080 12 GB 4K Dreamcolor

Во втором и экран 120 Герц против 60 в первом, но если второй будет подтупливающая печка работающая час от батареи, то как-то хз.

В первом же единственный плюс это видеокарта хоть и постарее, послабее и более прожорливая, но лишние 4 гигабайта видеопамяти лишними не будут, если пускать мелкие LLM локально через Ollama.

HT в обоих случаях отключаем в биосе, если что. Никакой Win11 и Thread Director’а не предполагается, а будет Ubuntu 24.04 LTS с полнодисковым шифрованием.

Сейчас пишу с i5-12450H, использую nosmt, ноутбук выключаю редко, пользуюсь suspend, вроде ничего не ломается.

Ядро всегда свежее (arch), сейчас 6.12.4.

Пробовал, кстати, intel-lpmd. При нём (и при работе от батареи) в основном используются E-ядра. Но особого увеличения времени работы не заметил (на глаз, точно не измерял).

Спасибо, попробую

Это на работе выдают?

Да. Дарят в пользование, скорее. Без возврата.

Попробовал. Та же ерунда - сиблинги не исчезают а офлайнятся - то есть не SMT вырубается а использование сиблингов не меняя нумерацию ядер. Соответственно шедъюлер их видит и пытается запросить их energy model - и получаем спам can nor get energy model for cpu2. Соответственно EAS не заводится. В текущем состоянии похоже ему нужен не софтверно спрятанный SMT а хардверно выпиленный SMT.

i9 + нвидия по любому печка как ни крути. Батарея и нвидия вместе не уживаются - либо одно либо другое.

по ужору именно на стороне проца - без доп усилий 13900 будет крутить все на P-ядрах. Но у 11950 тоже все будет крутиться на P-ядрах ибо других там просто нет. Там все ядра - P. То есть потенциально если научиться загружать E-ядра то 13900 должен быть лучше но по факту он будет просто не хуже.

Единственный тонкий момент - сейчас только ленивый блоггер не кинул в интел какашкой за то что 13-е и 14-е поколение производились на грязных линиях и дохнут как мухи при перегреве, особенно это коснулось геймеров которые практикуют overvolt и overclock.

Герцы пофигу (если не играть) - я свои сбросил со 120 на 60 ибо сильно + к батарее (особенно на воспроизведении всякой медиа) и глазом никаких ухудшений не вижу. Но скорее всего помимо ненужных герцев там еще и что-то с цветовым охватом (sRGB сейчас у всех почти 100%, а вот DCI-P3 и Adobe RGB - покажут что лучше) и с яркостью дисплея. Скорее всего на HP это сильно лучше - всетаки ноут гораздо более свежий.

Thinkpad P1 - хорошая надежная железяка, а вот HP Studio - шут его знает что за зверь.

Так что задачка сложная - и там засада и тут засада.

Я бы при таком выборе наверное взял HP как гораздо более современную платформу (хотя и исторически люблю ThinkPad) - но подстраховался бы на тему перегрева процессора - андервольт увы в ноутах невозможен но температурные лимиты и TDP подкрутить можно.

Скажи пожалуйста, а на офтопике такие же проблемы? или там интел успевает пилить ?

На оффтопике конечно успевает. Если твоя железяка не работает на основной системе для которой она предназначена - то нафига она тогда нужна.

Но опять же не нужно чтобы и приложения адаптировались и те же игры научились запрашивать от ОС исполнения на Р-ядрах. А тут пока вся эта масса повернется - шут его знает. Но рано или поздно повернется - в ARM это уже давно, АМД тоже уже активно пилит поддержку в ядро и скоро уже пойдут райзены с большимии малыми ядрами. Так что вектор развития намечен уже - большим и малым ядрам быть во всех системах.

Есть у меня подозрение что режим питания должен быть тогда энергосберегающий по умолчанию. В манджаро обычно баланс выставлен и переходит в режим производительности с играми. Конечно это дополнительные забавы с напряжением на разных частотах в биосе, но в принципе ограничение частот в разных режимах работы могли бы помочь, но не копал в этом направлении. И да, разнородные кластеры ядер это большая заморочка. Теперь понятно чего в играх когда сборка кривая Е и Р ядра так нагружены странно. Но там это решается встроенным видео ядром, еоторый убирает вагон паразитной нагрузки и процессор начинает потреблять в разы больше, хотя если движок кривой он все равно может жрать 45 ватт вместо 7-9 ватт. Мне казалось на ноутбуках эта проблема решена изначально методом использования видео ядра по умолчанию. Там вроде перестали баловаться ЦП без встройки. Так что актуальным остается лишь вопрос автономности, но других идей кроме удушения частот у меня нет. Ну или вручную отрубать все ероме пары ядер и скриптом запускать то что нужно подрубая нужное число ядер. Но это уже вариант для программ в основном, потому что игры должны жрать мало при использовании встройки и отдельной видеокарты, а не эти стадартные 50-80 ватт на ЦП. По крайней мере на ПК эффект очень сильный от использования встройки для отрисовки рабочего стола, подключения монитора, декодирования видео и вывода изображения на экран.

. Там же элементы UI поверх видеопотока еще надо рисовать. Как они это делают без шейдеров?

Как насчет того чтоб запечь все изображение окошек и UI в битмап, а место где идет видео сделать прозрачным в альфаканале.

Вопрос в том, как именно это реализовано в GPU. Насколько я понимаю, альфаблендинг делается пиксельным шейдером под управлением приложения.

А это будет совсем не то, как описано выше:

Как это делается в маке? Да вот так - броузер делает окошко в которое напрямую прямо в экранный буфер декодирует аппаратный декодер видео. Ни один 3д блок видеокарты при этом не активируется.

но ведь мноха ядер

потанцевал

ну может в маке альфаблендинг заложили в отдельный аппаратный блок вместо жручего шейдера.

встроенное видеоядро играм не поможет примерно никак - играм нужна дискретка. Ну вернее в случае с амд где и во встройке и в дискретке одинаковые видеоядра можно объединить усилия дискретки и встройки, а вот в случае с интел + нвидия врядли.

Единственное где помогает встройка - так это видеомонтаж, потому как набор аппратных медиакодеков у интела самый топовый, такого нет ни у нвидии ни у амд. В этом случае обработка идет на нвидии, а кодирование-декодирование отправляется на встройку.

Единственный тонкий момент - сейчас только ленивый блоггер не кинул в интел какашкой за то что 13-е и 14-е поколение производились на грязных линиях и дохнут как мухи при перегреве, особенно это коснулось геймеров которые практикуют overvolt и overclock.

Я быстро гуглил и вроде пишут, что это касается только мобильных HX процессоров, которые по сути есть десктопные, в то время как «истинно мобильные» процессоры с суффиксом просто H это не задело.

Не знаю насколько это правда.

i9 + нвидия по любому печка как ни крути.

Так мне хватило бы и встройки, но как будто во все конфигурации с топовыми дисплеями и процессорами пихают эти дискретки верхних линеек. Надеюсь в простое они не сильно греются и греют всё остальное.

Нет, лучше взять Intel. Нужно будет просто подождать, когда выйдет микрокод с раскрытием потенциала. И когда разработчики ОС научатся работать с инновационной архитектурой. Успешный AMD FX не даст соврать!

так амд тоже готовит little-big чипы. Получается хоть интел хоть амд - один хрен попадешь на инновационную архитектуру.

А значит у Линуса нет вариантов - либо прокачивать ядро под эти нововведения либо потесниться обратно с только что отвоеванных позиций на рынке и присесть на скамеечку лузеров вместе с хайку и фри-бсд. И интуиция подсказывает что Линус тут позиий не сдаст и будет поддержка little-big не хуже вендовой. Особенно учитывая что все эти little-big уже вполне себе чудесато работают в андроиде на проприетарных телефонных прошивках и арм.

А раз Линус заинтересован, интел заинтересован , амд тоже - то значит поддержка будет.

Патчи от амд уже в работе летают туда-сюда, тоже самое и с патчами от интела - к 6.14 скорее всего приземлятся, к 6.15-6.16 стабилизируются. Cachy патчсет с очень высокой вероятностью это сбэкпортит в LTS 6.12.

Ну а сейчас собрать и запустить intel-lpmd - и норм, комп начнет утилизировать E- ядра.

Еще через smp_affinity_mask можно зарулить прерывания от всякик клавиатур-тачпадов-мышей на Е-ядра, чтобы всякая мелочь пузатая не теребонькала жирные и жручие P. Так что даже сейчас инновационную архитектуру можно применить с пользой. Скажем на моем хоноре ни одно P-ядро от просто броузинга инета и ковыряния кода в редакторе даже не шевельнется. Зато при сборке свежего фокса из сорсов добротная 100% утилизация всех ядер и даже SMT сиблингов

Там же элементы UI поверх видеопотока еще надо рисовать. Как они это делают без шейдеров?

Когда-то давно, ещё до изобретения шейдеров, для этого был оверлей(XV)

Почему это не работает на текущей и лтс Убунте?

Потому что существует категория разработчиков, которым нужен большой дядя, который им скажет какая ОС оддерживается а какая нет. В случае МС и Яббла оно есть в случае линя нужно выбирать самому, и они стоят как буридановы ослы.

А он случаем не по пиксельной маске работал, в те времена до шейдеров? Не уверен, но кажется, что да.

типа того