У вас уже есть SWITCH 2 дома, проект 4IFIR

Что если я скажу Вам, что у Вас уже есть "Switch 2", с OLED экраном, DC Dimming-ом, технологиями VRR совместимыми со встроенным дисплеем, 60+ FPS буквально в любом проекте. Более того, у вас есть definitive edition версии всех самых знаковых проектов с первого Switch, причем такие, с которых версии The Legend of Zelda представленные на недавнем анонсе от Nintendo, могут разве что обтекать.

Что такое 4IFIR? Это AIO решение, основанное на глубоко модифицированном коде от Nintendo (в виде Open Source реимплементации HOS - Atmosphere) и Nvidia (Tegra X1 BDK), с комплексом из Homebrew сателлитов, как самостоятельных, так и являющихся модифицированными версиями проектов от сообщества.

Я - разработчик проекта 4IFIR для Nintendo Switch, на закате поколения хочу подвести итог пройденного пути и поделиться дальнейшими планами, в том числе экспансии проекта на новые платформы (AMD SOC совместимые).

За 3 года стремительного развития, то, что начиналось как продвинутое решение для разгона Nintendo Switch, эволюционировало до самого продвинутого решения для разгона в принципе, вопреки развитию не столько как решение для разгона, сколько как решение для повышения производительности на ватт, развивающее как базовые свойства системного ПО, так и надстраивающее принципиально новые возможности (например, имплементация технологии VRR, совместимой со встроенными дисплеями, интерактивная система разгона памяти в реальном времени, и множество других продвинутых кастомных решений, объединенных в экосистему, образующих в синергии то, что можно без оговорок охарактеризовать как - бесплатный программный апгрейд на полтора консольно-аппаратных поколения).

Незнакомый с 4IFIR-ом читатель, на этом моменте, вероятно, поймал себя на мысли: "чего бл*ть?!", что не удивительно. Мало кто ожидает встретить проект с подобным описанием, на "Китайском планшете на базе SOC от FPV дрона, устаревшего еще до анонса платформы", для того чтобы разобраться, как мы к этому пришли, и в каком виде проект планируется перенести на x86 совместимые "портативные" консоли (в виде мастер-референса - для STEAM DECK, и всего необходимого, для упрощенной реимплементации энтузиастами из сообщества - для других "портативных консолей" на SOC AMD), предлагаю краткую ретроспективу.

В конце статьи мы рассмотрим на практических примерах ряд повседневных кейсов, использующих тандем из доступных возможностей - в полной мере. Т.е. пофлексим с того, что имеем в моменте (UPD. В статью не влезло, рассмотрим следом, простите).

4IFIR практически со старта совместим с обеими аппаратными ревизиями Tegra X1, но дабы не перегружать читателя контекстом, референсные значения будут привязаны ко второй ревизии (SWITCH Mariko, вкл. Lite и OLED модели). Несмотря на асинхронный календарь релизов, в настоящий момент фичсет между ревизиями почти равноценен, с поправкой на производительность на ватт, обусловленную дельтой техпроцессов (~20%).

Для простоты восприятия, ввиду того что в контексте 4IFIR-а, производительность и энергопотребление на удельный мегагерц каждого из компонентов, как ни странно, являются переменными, я буду оперировать преимущественно конечными метриками - игровая производительность, энергопотребление. В конечном счете, всё сводится к тому, сколько игровой производительности на единицу TDP вы можете себе позволить.

Стоковые значения и константы: Ёмкость аккумулятора Switch Lite - 13.6wh. У остальных моделей - 16wh.

"16wh" означает, что аккумулятор способен отдавать 16 ватт мощности в течение часа. Или 8 ватт в течение двух часов и так далее.

Энергопотребление стоковой консоли в портативном режиме, в графически нагруженных проектах, в среднем составляет 5 ватт. Около четырех в нетребовательных играх.

Следующее примечание для понимания требует концентрации, оно душное. К сожалению, оно обязательно для понимания наиболее контринтуитивных условностей, из которых складывается Ваше ощущение "плавности", отзывчивости, стабильности производительности, и в конечном счёте "комфортности" игрового опыта:

Фиксированная частота развертки в 60Hz и "неотключаемый" VSync на системном уровне (поверьте, вы не хотели бы его отключать) означают, что единственный "рабочий" сценарий производительности с консистентным временем кадра, помимо stable 30fps fixed (интервал fps к hz 1 к 2), это stable 60fps fixed. Любые промежуточные варианты, включая хоть немного нестабильные 60fps, рано или поздно вызовут у вас сильное желание зафиксировать фреймрейт на ближайшем кратном интервалу значении FPS, лишь бы с консистентным временем кадра. Вывод: "Попробовал я эти ваши 60fps, ничего особенного, вернулся на 30fps", в подавляющем большинстве случаев вытекает из незнания вышесказанного в тандеме с нестабильными 60fps.

Понимание вышесказанного на уровне интуиции у кого-то сформировалось с личной пробой технологии VRR, у кого-то - с приобретением Steam Deck (с доступным на видном месте ползунком частоты развертки и "народными" 40Hz), но для большинства геймеров всё еще малоочевидно, почему старый добрый индикатор FPS вдруг уступил по важности какой-то душной консистентности времени кадра.

Последний факт, необходимый для понимания масштаба проблемы Nintendo Switch в его стоковом состоянии, состоит в том, что назвав stable 30fps fixed "рабочим вариантом", я слукавил. Если Вы играли в 40Hz при стабильных 40fps, то наверняка заметили, что эти 40fps по какой-то причине ощущаются по игрaбельности куда ближе к 60fps, нежели к 30fps. Опытным путём были сделаны выводы, подтвержденные опрошенными участниками эксперимента из сообщества, что минимальное значение частоты развертки при стабильном фреймрейте, несравнимо более играбельным в сравнении с 30fps при тройной буферизации, выступает значение в 37Hz с дельтой между опрошенными участниками в 2Hz. Что любопытно, уже после определившегося среднемедианного значения в 37Hz, участники выборки сошлись на единогласном мнении, что 37Hz, наверное, точнее и ближе к их конечному выводу. Магическое число, не иначе.

Исключение - игры с двойной буферизацией, крайне малочисленные, и в относительно требовательных проектах, на платформе, за пределами игр от самой Nintendo почти не встречающихся (30). Если не брать их в расчёт, мы получаем весьма безрадостную картину начальных условий, где за пределами игр от самой Nintendo и играми инди-жанра, на OFW - проще сказать, что играбельных игр больше нет, чем обмазываться игровым опытом, сравнимым с плаванием под наркозом в желеобразной жиже, с гирями привязанными к яй.. рукам. Недостаточно производительности для стабильных 60fps? (на OFW их недостаточно даже Hades, не говоря уже о более требовательных и менее оптимизированных проектах), извольте страдать.

Я не смог стоять в стороне и позволить вам страдать лишь потому, что Nintendo решила сэкономить пол-доллара, закупив жмых от чипов с распродажи Nvidia. Предстояла долгая работа, чтобы сделать из этого Switch 2 Pro за года до анонса Switch 2.

Предстояла капитальная исследовательская работа, перед тем как символический разгон с огромным штрафом к энергопотреблению эволюционирует в то, каким 4IFIR известен его пользователям из настоящего. И это я еще понятия не имел, сколько коварства и подлости встанет на пути, пытаясь помешать мне доставить Вам мой замысел - с целью подарить, ни за что, просто так, потому что могу. Если бы догадывался, я бы доставил Вам ништяки быстрее, так как не стал бы церемониться с подонками, решившими что Вы его недостойны, посылая каждого подлеца поговорить с рукой сразу.

Я сознательно скипну скучную часть, акцентируясь на прецедентах, установленных 4IFIR-ом на пути развития. Такие штуки, которые в экспертном сообществе считались нереализуемыми, а оказалось, что они считали неправильно.

Вдохновившись proof-of-concept-ом разработчика KimPossible, была выстроена база, скелет будущего проекта, где первой важной задачей было упростить метод доставки решения, упростив с точки зрения пользователя процесс с "необходимо быть сениором-помидором" до "распаковал, включил, наслаждаешься".

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

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

Первое время, в зависимости от конкретных чипов DDR, установленных в консоль, удавалось добиться прироста со стоковых 5200MBs (покрывающих издержки стоковых 480MHz GPU без дефицита) до 6100-6300MBs. Этого все еще было недостаточно, чтобы вырваться из вышеописанных ограничений, но стабилизировать тот же Hades на 60fps ценой приемлемого роста TDP, и чуть большей ценой стабилизировать некоторые ресурсоемкие проекты на более-менее стабильных, но все еще малоиграбельных 30fps, уже хватало.

Потенциал подхода работы над КПД при ближайшем рассмотрении был виден уже тогда.

Решив отдохнуть от оперативной памяти, я переключил фокус на то, чтобы "невозможный" андервольтинг GPU, самого прожорливого компонента, ко всеобщему удивлению, стал не просто возможен, а еще как возможен. Так например, в дефолтное напряжение GPU для портативного режима работы в 610mV для GPU, на подавляющем большинстве устройств удалось добиться стабильной работы более 800MHz эффективной частоты (при заводских 460MHz). Без изменения напряжения. Ниже 610mV стоковая консоль напряжение не снижает ни на какой частоте. Разве что во сне.

Довольный результатом, я вернулся к работе над оптимизацией памяти. На тот момент у меня не было готового решения, позволяющего снизить напряжение на GPU ниже стоковых 610mV, а частоте в 8ххMHz GPU испытывала явный дефицит полосы пропускания, раскрываясь при 6200MBs далеко не в полной мере. Глаза боятся - руки делают, на рождество под елку - был доставлен подарок горячей доставкой, в виде более продвинутой и комплексной системы оптимизации таймингов, и почти одновременно с этим - оптимизации, позволяющие снять лок для большинства чипов с 1996MHz средней частоты до значений в 2400MHz. Не сразу, не везде, но постепенно, релиз к релизу, эта частота была стабилизирована на всех чипах. Что гораздо важнее, параллельно с повышением частоты была проведена масштабная работа по реализации её потенциала, обвешавшись спецификациями и технической документацией, я начал закладывать основы для того, что впоследствии не только заменит не предусмотренный по задумке для low profile чипов/чипсетов для этих чипов функционал по разгону памяти вроде того, что есть в BIOS, а, как ни странно, заметно превзойдет эти возможности в перспективе.

Но до этой перспективы нужно было еще добраться. С помощью простейшей арифметики, не трудно догадаться, что условные 6900-7100MBs, доступные с 2400MHz, всё еще были далеки от потребностей 8ххMHz GPU. А отсутствие возможности на тот момент уйти в ECO-номичные режимы с одновременным повышением производительности всё еще казались чем-то из области фантастики. Глаза боятся - руки продолжают. Долго ли коротко, эффективность продолжала расти. Обратно-пропорционально росту эффективности снижалась планка подлости, на которую готовы были опуститься все те, кто оказался множество раз не прав, чтобы 4IFIR мог существовать. Примерно в это же время вокруг 4IFIR-а начал воспламеняться хайп, появилось первое сообщество, объединившее хейтеров проекта, практически неотличимое от секты. Начали проглядываться первые признаки подражателей, вдохновленные успехами 4IFIR-а и пытавшиеся максимально кринжово пародировать меня, вплоть до перешучивания моих шуток. Не спрашивайте, поверьте, Вы не хотите знать подробности о жизни городских сумасшедших, промышлявших подделками 4IFIR-а, по сути, собранными из мусорных отходов моего производства. Это паразитирующее явление до сих пор живо, Вы могли слышать о нём под разными названиями, объединенными в категорию "альтернативные сборки для разгона" (альтернативные, по словам сборщиков zip-архивов с подделками, 4IFIR-у, при том что основаны они на его же оптимизационной базе, на текущий момент уже трехлетней давности, с рудиментарными вкраплениями того, что удалось присобачить в "альтернативы" из более поздних релизов, остерегайтесь подделок).

Примерно к 7700MBs все с тех же 2400MHz частоты RAM я внезапно обнаружил, что если ужать динамическое разрешение, слегка подрезать графические эффекты и задавить дефицит пропускной - избыточными частотами CPU/GPU, внезапно мы получаем входной билет в 60fps в основной массе проектов на Switch. Тогда это казалось фантастикой, но это было только начало. И все еще относительно дорого по TDP.

Глаза уже привыкли, а руки продолжали делать. Проект помимо качественно-количественного роста обрастал мясом, quality of life изменениями/нововведениями, оптимизированными сателлитами. 7900MBs... 8100MBs... (параллельно с этой важнейшей цифрой рос КПД эффективности на мегагерц CPU/GPU).

Прорывом стало внедрение системы (не смейтесь, у неё нет прямых аналогов, так что я назвал её в честь того, что я думал на тот момент об активнейшей травле проекта со стороны горе-хейтеров с Западной сцены) - eBAL (EMC BALLANCE ADVANCED LOGIC).

Что такое eBAL? Это низкоуровневая комплексная система, вдохновленная способностью Морфлинга из Доты (лол) по перекачке силы в ловкость и обратно. Для многих из вас не секрет, что сила и ловкость косвенным образом влияют на самые разные характеристики героя. Так и здесь, от режима eBAL (1-2-3-4-5) зависит чуть ли не каждый аспект памяти. От того, какие она может стабильно взять тайминги, до частоты, всех связанных напряжений, с ОЧЕНЬ БОЛЬШОЙ натяжкой, чем-то отдаленно напоминающим eBAL, является механизм CL, известный каждому, кто вникал в контекст оверклокинга памяти.

Самое короткое определение механизма выглядит так:

// TRADE MAX FREQ FOR EFFICIENCY // EFFICIENCY << PRIORITY >> FREQUENCY

От частоты памяти на Tegra X1 зависят voltage min значения. Я упоминал выше 610mV, так вот для стабильной работы на частотах выше 2400MHz, в числе прочих частотных оптимизаций, мы сталкиваемся с необходимостью повышать напряжение voltage min для CPU и GPU, независимо от того, требуется нам это напряжение для самой частоты CPU/GPU или нет. Из этого следует важный вывод:

В моих/наших интересах впрессовать как можно больше полосы пропускания на 1 mhz тактовой частоты. Любой ценой, вроде повышения напряжений самой памяти при прочих равных, так как это будет оправдано возможностью не повышать voltage min для наиболее прожорливых компонентов.

Это стало на порядок актуальнее после того, как мне удалось добиться возможности опуститься ниже минимального порога vmin для CPU и GPU (620 и 610mV соответственно). Так например, для стоковых 460MHz оказалось более чем достаточно ~475mV GPU и ~495mV CPU. Однако такие значения требовали снижения частоты EMC практически до заводских 1331MHz, что возвращает нас к 5200MBs.

Самые внимательные из Вас спросят, Куллер, а зачем 460MHz больше полосы пропускания, чем доступно в стоке, ты же сам сказал, что это как раз удовлетворяет потребности, 5200MBs? Заметили? Молодцы. Нет? Все равно красавцы. Отвечу. Дело в том, что в 4IFIR-е на тот момент уже были доступны прошедшие не один эволюционный этап частотные GOVERNOR-ы. Поскольку игровая нагрузка неравномерна, нет никакого смысла кочегарить на фиксированных максимальных значениях частот GPU все время. Там, где для поддержания целевого фреймрейта приходится выставить CPU/GPU в условные 1.4GHz/0.8GHz соответственно, обычно есть ситуативная возможность сбрасывать в не самых нагруженных сценах/локациях частоты вплоть до 0.8GHz/0.5GHz. 4IFIR делает это автоматически, не жертвуя кадрами фреймрейта, по необходимости возвращая частоты к верхним целевым. Чем ниже частота, тем меньше нам нужно напряжения для её поддержания. Экономия. Еще больше бесплатной производительности. 4IFIR именно про это.

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

Так, с их точки зрения, немощный CPU при напряжении в 1.235mV не способен удержать штангу весом в 2.4GHz. «Вася, извини, не могу, тяжело».

Каково же было удивление этих одухотворенных гениев, когда выяснилось, что для 2.4GHz большинству семплов оказалось достаточно чуть ли не 1.0v ровно.

Я не буду душить Вас всеми опровергнутыми «гениальными» умозаключениями, рожденными фантазией моих неудавшихся отменителей, скажу лишь, что они каким-то чудесным, не укладывающимся в моей голове образом, умудрились навязать под три десятка подобных споров о невозможности, разгромно и показательно слив во всех спорных тезисах без исключений. Это особенно удивительно, если знать, что споры навязывались не постфактум, а сильно заранее, на этапе гипотез, когда я сам все ещё не мог с уверенностью что-то констатировать. Тем не менее, это один из парадоксальных фактов истории проекта. Они так долго работали над тем, чтобы эта статистика стала реальной, что в какой-то момент в сообществе завирусился анекдот, согласно которому я настолько самоуверен, что моя уверенность создаёт вокруг меня Waaagh! поле такой мощности, что оно искажает пространство и время, подстраивая реальность в соответствии с любым моим утверждением, какими бы бредовыми они изначально не были. Шутка смешная. Ситуация страшная.

Таким образом, мы получили 60fps в mediocore проектах за чуть больше чем в стоке TDP. Там, где в стоке было 30fps с просадками. Не дурно? Я так не считал, и историю мы только начали. Нужно больше производительности за меньше ватт. Глаза сверкают, руки рвутся в бой. Казалось бы, какие прорывы можно совершить на этом этапе?

Возможность смены частоты развертки дисплея. Вы же помните про волшебные 37-45Hz? Которые ощущаются куда ближе к 60, чем к 30. Сначала я внедрил саму возможность смены частоты развертки (впоследствии я реализовал управление частотой развертки дисплеем - в том числе, подключенных по HDMI, помимо встроенного экрана консоли). Для Switch-а эта возможность стала настоящим геймчейнджером. Больше не нужно пытаться рвать ср*ку для удержания стабильных 60Hz/fps, заливая их избыточными частотами. Достаточно залить избыточными частотами хотя бы 40Hz/fps, чтобы стало классно.

Пока все радовались и плясали, большинство консолей на 4IFIR-е перешагнули за порог в 10000MBs. Сначала на частотах вроде 2665, потом ниже, ниже, на сегодняшний день практически любой семпл второй ревизии позволяет взять 10К в пограничном с ECO режиме работы (ECO в 4IFIR-е - это то, что позволяет получить большую автономность, чем в сток-дефолте). Буквально уместить их в стоковые 5W. Было 30fps с просадками, держите 74Hz/FPs из ничего, те же 5 ватт, рвись шаблон, выкуси устоявшееся и привычное.

На более удачных семплах (4IFIR все возможные разбеги по качеству кремния плюс-минус уровнял, позволяя в каждом отдельно взятом устройстве найти индивидуальный сильный аспект, и не один) эти 10к MBs вполне вписываются с ECO режим. Например, в 4.х ваттный total power draw.

Следующей судьбоносной вехой стала реализация эксклюзивной имплементации технологии VRR. Эксклюзивной, потому что проприетарные Gsync и FreeSync, Китайский планшет не то чтобы не поддерживал, этих технологий даже в проектах не было, когда Switch успел устареть аппаратно. Ни OS, ни драйвера, ни дисплеи, ни интерфейсы программные и аппаратные, ни протоколы в гробу видели технологию VRR. Ваш покорный слуга не просто реализовал "аналог", а буквально сделал этот аналог значительно более продвинутым, чем оба проприетарных предшественника. Как функционально, так и по сухим TTX. Что самое ироничное, на Switch-е, на встроенных дисплеях, технология вроде VRR раскрывается так, как нигде больше, она вписалась туда так, словно была там изначально. В это же время анекдот про Waaagh! перестал казаться анекдотом.

VRR позволил решить проблему, описанную в первой трети статьи. Больше не нужно заваливать установленную частоту развертки избыточными частотами вычислительных компонентов. Теперь частота развертки дисплея с активным VRR работает как Target значение, для которого достаточно дать частоты CPU/GPU/пропускную способность памяти впритык, а VRR не позволит выпасть кадрам, плавно подхватывая и сглаживая (да, реализация в 4IFIR-е, в отличие от проприетарных аналогов, "умная", она не просто уравнивает частоту развертки в соответствии с FPS, она еще и устраняет единственное несовершенство проприетарных аналогов - решая за frametime consistency issue) развертку в соответствии с вычислительным бюджетом.

Возможность независимо от колебаний фреймрейта иметь консистентное время кадра позволило вывести в тренд бескомпромисные режимы работы, с модификацией на значительно улучшенную графику/разрешение, значительно лучшую производительность/фреймрейт (любой фреймрейт стал рабочим, а не только 60Hz solid strong).

Спустя несколько итераций/обновлений, VRR преисполнился настолько, что и на IPS, и на OLED избавился от каких-либо побочных явлений, ухудшающих/снижающих что-либо, вроде цветовой точности, так он еще и обзавелся runtime свойствами, расширяющими цветовое пространство. Я не буду называть это HDR, но сам диапазон значений частоты развертки в моменте подобрался к 37-64 для OLED (это не предел) и 32-74Hz для IPS (и это тоже не предел), обзавелся адаптивным DC Dimming-ом (совместимым не только с любой частотой развертки, но и с VRR в частности), устранил проблемы работы с цветовыми нормалями, присутствующими в HOS в стоке. К этому моменту каждый Switch стал способен взять полосу пропускания памяти в 11000MBs, а некоторые чипы аж 12000MBs, что позволило раскрыть потенциал без каких-либо намеков на дефицит уже для ~1GHz GPU. К слову, с дефицитом, там где доступен огромный запас по TDP, вроде режима дока, Вы легко можете выставить полтора гигагерца, это тоже стало возможным - после решения нескольких головоломок в процессе.

Кстати, да, невероятно - но факт. Думаю, не нужно объяснять, почему свободно распространяемое ПО для разгона подразумевает очевидный отказ от ответственности за возможные последствия, всё это прописано в дисклеймере проекта. Как само собой разумеющееся, создавая проект, я заложил для себя планку приемлемого процента отказов устройств у самых неосторожных и безответственных участников, для решения такого класса - в 1%, посчитав его ��чень скромным.

Инсталлбаза 4IFIR-а к новому году перевалила за 2млн относительно активных установок, если верить статистике веб-сервера. Дальше я уже не мониторил. Проект существует более 3х лет. Внимание, вопрос:

Как Вы думаете, сколько устройств на 4IFIR-е вышло из строя - по вине 4IFIR-а?

0 подтвержденных случаев. Не 0%, а просто 0. Не ищите подвоха в слове "подтвержденных", я не только внимательно изучал все обращения, но и искал те, что прошли мимо, отписывался в комментариях в паре публикаций на reddit-е, что-то было снято с повестки топикстартером (не подтвердилось, все работает, забыл как включать консоль, утрирую, но вы поняли), что-то просто уходило в тишину без малейших попыток привести хоть какие-то свидетельства проблемы (хотя бы фотографию с выключенной консолью с ближайшего стока, ничего, а я обещал первому - у кого отлетит консоль, свою собственную, чтобы отметить открывшийся счёт на убийства, да только воз и ныне там, ноль, парадокс, выкуси здравый смысл еще раз).

И вот казалось бы, что еще нужно для счастья?

Интерактивный разгон памяти реального времени, порог входа в самый продвинутый разгон памяти с наносекундной точностью, о котором не мечтают профессиональные оверклокеры, до уровня сложности игры в Flappy Bird. Я почти не утрирую. Взгляните на тех, кто воспользовался. Видите, какие у них лица блаженные, счастливые? А Вы видели, как они на меня смотрят? Ну так вот.

Близится к концу поколение, близится переход проекта на новые платформы. Но перед этим, вероятно, я успею выпустить важнейшее из обновлений, Magnum Opus 4IFIR-а на Switch, с кодовым названием Mode 7. Я заспойлерил его свойства core сообществу, мне и вам рассказать не жалко, но я предлагаю попытаться угадать самостоятельно, что там такого может быть, если каждый следующий 4IFIR подчиняется правилу - быть высокобюджетнее и невозможнее предыдущего? Последний релиз, к слову, повысил планку до технологии, которую пыталась, но сломала зубы и передумала реализовывать Intel в лучшие годы. Абсурдно звучит, но по сути, технология оказалась им не по карману. Следующая будет дороже и круче.

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

Пожалуйста, не отходите далеко.

Пользуясь случаем, у меня символическая просьба. Не хочу Вас обременять лишними хлопотами, но если у Вас есть на примете подхящая работа/вакансия, где мои навыки могли бы пригодиться, я буду бесконечно признателен. К сожалению, по состоянию здоровью, на какое-то время выпал из графика, теперь, когда я снова в санях, вопрос стал срочным, Вы в буквальном смысле, можете меня спасти :( Буду вашим должником.

С уважением,

Ваш друг, Cooler3D