Если на мгновение представить, что ограничения приняли по просьбам трудящихся родителей, возникнут вопросы к реализации. Она обременяет всех, хотя не должна. Она несоразмерна цели - защищать детей. Возможно создать схему, в которой сайт уважает флаг о несовершеннолетии, посылаемый с устройства (выставляемый родителями на залоченном устройстве). Во времена, когда рутование телефонов отмирает, винда требует TPM, а античиты - Secure Boot, это схема надёжная. Неужели требовательные родители так хотят свалить воспитание на государство, что против схемы с контролем ими детских устройств (во времена, когда контроль становится всё проще)?
Если не представлять, то тогда интересно, насколько легко проглотили всемирный поворот к авторитаризму. Почему? Избиратели с пониманием относятся к отговорке про детей и приветствуют закручивание гаек крепкой рукой во власти? Или здесь всегда что-то другое? Безразличие / страх репрессий / баг психики, позволяющий заклеймить детоненавистником (и удалить из политики) всех, кто начнёт говорить про соразмерность и обременения в контексте детей?
Цитата в тему: "Why can't you believe that someone would want to press 1 button instead on 5?" (r/Kodi).
Kodi подталкивает к составлению библиотеки и ухаживанию за ней (ручное создание .NFO-файлов или настройка скрейперов), это "единственный верный способ".
Но библиотека может (или обязана*) рассинхронизироваться с файловой системой, а обновление библиотеки может тихо ломаться на конфликтах.
Открытие файлов через файловую систему выигрывает в том, что это single source of truth, он не может сломаться, он не требует правильной файловой иерархии, .NFO файлов рядом с видео, которые Kodi должен вовремя увидеть, добавить в свою базу (без гарантий, что он успеет сделать это за разумное время на крупной библиотеке) и не поломать её. Но всё-таки Kodi сильно завязан на библиотеку.
* "The only way you can add to the library is with a designated scraper, or manually created .info files and re-scanning" - forum.kodi.tv (это часто приходилось делать вручную).
Нет, я про возможность проигрывать видео и в то же время, независимо от видео, музыку. Так нельзя, здесь однозадачность. "Use a regular OS, if you need background music" - говорит модератор forum.libreelec.tv.
С фотографиями тоже непонимание. Веб-галереи опираются на то, что уверенный пользователь телевизора может просто выйти из Kodi. И вся драма в том, что в *ELEC он не может. Он сделал себя заложником Kodi, установив *ELEC.
Что может сделать пользователь *ELEC, чтобы воспользоваться PhotoPrism'ом или другой аналогичной галереей? Как я понимаю, ничего. Вот пользователь LibreELEC и Piwigo жалуется, что не видит способа подружить их и смотрит фотографии из папки.
У *ELEC'ов проблема особенность в том, что там нет жизни за пределами Kodi. Нельзя запустить браузер / проигрывать музыку фоном / принимать поток Miracast, потому что это нельзя сделать через Kodi. Если такие ограничения устраивают, то неплохая вещь.
Но это довольно серьёзные ограничения. Значит, для музыки нужно другое устройство, а фотографии не-на-диске просмотреть невозможно, даже если это self-hosted веб-галерея типа PhotoPrism (ну, потому что она веб-, её клиент - браузер; который тут совсем нельзя).
Значит, редакторы heise.de проиграли, играясь словами, а редакторы хабра - нет. Heise.de на этих словах ссылаются на другую свою статью, где про разблокировку фич ничего нет.
Только повторяют про обнуление SMART и переклеивание этикеток, чтобы продавать б/у по ценам новых и свежих дисков. И проясняют, что этикетки от дисков более дорогих.
Видимо, менеджерам было невыгодно признавать ошибку. Удалить совсем - их решение. Отменить удаление - значит, показать свою ошибку. Спрятать режим - компромисс, можно лицо сохранить.
точно объяснить как это всё работает? Я смотрю, пока всё это на уровне "я на ютубе смотрел"
Вникать глубже ютубовского уровня - это значит самому поковырять FidelityFX SDK или самому подключать FSR 3 к Unreal Engine, так что сомневаюсь. Статья от Nvidia существует в виде ролика на ютубе, а статьи Techspot часто дублируют на канале Hardware Unboxed. Разве что пересказы или переводы таких материалов тут будут (или уже были).
Вместо статьи: производители видеокарт взяли алгоритмы из уплавнялок для видео, добавили информацию о движении из игрового движка (motion vectors). Плавность игр выросла, задержки (latency) тоже выросли.
Вы всё-таки или всё перепутали, или делаете невероятно сильные заявления, но в любом случае мне нужны источники. Ох, ладно - и первое, и второе, а если источник путаницы в каком-то блоге, то он ведь только для чёрного списка сгодится.
Если покороче, то вот ещё более ясный текст: "The FidelityFX Frame Interpolation technique takes 2 back buffers, and several resources shared with FSR3Upscaler and FfxOpticalFlow to compute an interpolated image between the 2 back buffers" - FidelityFX-SDK-FSR3. Сначала два готовых отрендеренных кадра, потом генерируем кадр между ними. Никакой магии.
"Закрашивает получившиеся дыры" - это Inpainting в Reflex Frame Warp (та же статья на nvidia research). Только там заявляется, что кадр экстраполируется, а не интерполируется.
В Reflex 2 не заявлено рисование выстрелов и попаданий. Только "деформация кадра".
Апскейл "будущего" опорного кадра интересен тем, что если апскейл тоже надо ждать, он должен добавлять ещё несколько миллисекунд задержки.
Не готово, а ещё оптический поток (ради "particles, reflections, shadows, and lighting"), который требует 2 отрендеренных кадра (не motion vectors).
Nvidia пришлось бы опровержения не только для tomshardware писать, но и для hwcooling.net: "A major complication is that to interpolate an intermediate frame, you first need to have the previous frame and the following one available. So when using FSR 3 or DLSS 3, the game must buffer one extra frame before displaying".
Да, впрочем, Techspot смотрели на фреймген в DLSS4 в нативном разрешении - задержка тоже растёт.
Суметь без рендеринга отобразить данные, которые возникли позже последнего честно отрендеренного кадра - это ценная магия, но она ограничивается ещё не вышедшим Frame Warp.
"Reflex Frame Warp ... we explored predictive rendering; instead of always rendering from a strictly player-centered viewpoint, we extrapolate camera movement from user input" - https://research.nvidia.com/labs/adlr/DLSS4/
Думаю, если бы оно работало как "Генерация берёт старый кадр, геометрию нового кадра", то это был бы повод для гордости, сравнимый с Frame Warp (=> были бы публикации) и о нём тоже бы говорилось со словами "predictive rendering", "extrapolate". UPD: также пришлось бы публиковаться, чтобы показать прогресс по сравнению с DLSS3 и конкурентами и чтобы сообщить, что их дважды неверно поняли (опровергуть подчёркнутое): "Jensen says DLSS 4 'predicts the future' to increase framerates without introducing latency (Updated: Nope)" - tomshardware.
Это описание так ужасно расходится со словами Nvidia и бенчмарками, что очень хочется знать, откуда оно.
По Nvidia "будущий" кадр готовится целиком (рендерится и апскейлится*) а промежуточный в DLSS3 интерполируется на основе "information from the game motion vectors, the optical flow field, and the sequential game frames [т.е. предыдущего и этого "будущего" кадра]".
"1 кадр задержки" тут в значении "1/fps", без погружения глубже, без размышлений о конвейерах.
Иллюзия магии ("задержка вывода информации уменьшается") возникает, потому что забывают про апскейл (который работает вместе с фреймгеном) и сравнивают не с DLSS-без-фреймгена, а с нативом - то есть с другим разрешением. Input Latency у Techspot под спойлером растёт относительно DLSS-без-фреймгена, как и должно быть.
Reflex по Nvidia оптимизирует render queue, чтобы кадры не скапливались и поспевали к оптимальному моменту (тут команды от CPU к более удачному моменту отложить, там частоту GPU на мгновение приподнять). Из возможностей изменения картинки заявлены только планы на будущий Reflex Frame Warp примерно как в шлемах.
* на схеме оптический поток работает с апскейленными кадрами.
Только его можно очень по-разному оверселлить. Всегда удивляли американские истории про 1.2 ТБ на месяц. В худшем случае часа три интернета. А бэкап на пару терабайт только почтой.
Мне здесь компетенций не хватает, но что-то совсем не так. Конкретному решению (поставить параллельно керамику) нужна конкретная проблема, а если опасаться чего-то неопределённого, то это плохо кончится зачем оставлять электролит?
Если опасаться чего-то неопределённого на резонансной частоте конденсатора или за ней, то это вопрос не к электролиту, а к большому номиналу, который выбрали в vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
который будет недопускать ввода-вывода (не суть важно, как именно, просто представим, что может)
Тогда не стоит его называть [[gnu::pure]] - этот атрибут не про гарантии от компилятора для программиста*, а наоборот - программист обещает компилятору, что функция чистая:
In short, you shouldn't be saying it's pure or const if it's not pure or const ... if the user is marking trivial functions const or pure when they clearly aren't, they deserve what they get :). ... attributes are meant for when you are sure you know more than the compiler can tell - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Нормальные люди переименовали бы его в [[gnu::assume_pure]]...
LTO-8 уже только одно поколение вниз, LTO-10 - ноль поколений.
И, думаю, LTO в домашних условиях больше про "шашечки", чем про "ехать".
* Чтоб боковая панель (с вкладками или неважно чем) начиналась от верхнего края окна?
Если да, то здесь есть мысли про реализацию через userchrome.css (без полноценного решения):
https://old.reddit.com/r/FirefoxCSS/comments/16vze6x/
https://github.com/mbnuqw/sidebery/discussions/1648
А здесь обсуждалось как встроенная функция браузера:
https://bugzilla.mozilla.org/show_bug.cgi?id=61848
https://bugzilla.mozilla.org/show_bug.cgi?id=200427
"Opened 25 years ago" - настоялось!
"Updated 14 years ago" - прокисло!
Если нет, то это очень непонятная фраза.
Если на мгновение представить, что ограничения приняли по просьбам трудящихся родителей, возникнут вопросы к реализации. Она обременяет всех, хотя не должна. Она несоразмерна цели - защищать детей. Возможно создать схему, в которой сайт уважает флаг о несовершеннолетии, посылаемый с устройства (выставляемый родителями на залоченном устройстве). Во времена, когда рутование телефонов отмирает, винда требует TPM, а античиты - Secure Boot, это схема надёжная. Неужели требовательные родители так хотят свалить воспитание на государство, что против схемы с контролем ими детских устройств (во времена, когда контроль становится всё проще)?
Если не представлять, то тогда интересно, насколько легко проглотили всемирный поворот к авторитаризму. Почему? Избиратели с пониманием относятся к отговорке про детей и приветствуют закручивание гаек крепкой рукой во власти? Или здесь всегда что-то другое? Безразличие / страх репрессий / баг психики, позволяющий заклеймить детоненавистником (и удалить из политики) всех, кто начнёт говорить про соразмерность и обременения в контексте детей?
* через файловый менеджер, то есть.
Ещё есть некоторая драма с интерфейсом в Kodi.
Цитата в тему: "Why can't you believe that someone would want to press 1 button instead on 5?" (r/Kodi).
Kodi подталкивает к составлению библиотеки и ухаживанию за ней (ручное создание .NFO-файлов или настройка скрейперов), это "единственный верный способ".
Но библиотека может (или обязана*) рассинхронизироваться с файловой системой, а обновление библиотеки может тихо ломаться на конфликтах.
Открытие файлов через файловую систему выигрывает в том, что это single source of truth, он не может сломаться, он не требует правильной файловой иерархии, .NFO файлов рядом с видео, которые Kodi должен вовремя увидеть, добавить в свою базу (без гарантий, что он успеет сделать это за разумное время на крупной библиотеке) и не поломать её. Но всё-таки Kodi сильно завязан на библиотеку.
* "The only way you can add to the library is with a designated scraper, or manually created .info files and re-scanning" - forum.kodi.tv (это часто приходилось делать вручную).
Нет, я про возможность проигрывать видео и в то же время, независимо от видео, музыку. Так нельзя, здесь однозадачность.
"Use a regular OS, if you need background music" - говорит модератор forum.libreelec.tv.
С фотографиями тоже непонимание. Веб-галереи опираются на то, что уверенный пользователь телевизора может просто выйти из Kodi. И вся драма в том, что в *ELEC он не может. Он сделал себя заложником Kodi, установив *ELEC.
Что может сделать пользователь *ELEC, чтобы воспользоваться PhotoPrism'ом или другой аналогичной галереей? Как я понимаю, ничего. Вот пользователь LibreELEC и Piwigo жалуется, что не видит способа подружить их и смотрит фотографии из папки.
У *ELEC'ов
проблемаособенность в том, что там нет жизни за пределами Kodi. Нельзя запустить браузер / проигрывать музыку фоном / принимать поток Miracast, потому что это нельзя сделать через Kodi. Если такие ограничения устраивают, то неплохая вещь.Но это довольно серьёзные ограничения. Значит, для музыки нужно другое устройство, а фотографии не-на-диске просмотреть невозможно, даже если это self-hosted веб-галерея типа PhotoPrism (ну, потому что она веб-, её клиент - браузер; который тут совсем нельзя).
Значит, редакторы heise.de проиграли, играясь словами, а редакторы хабра - нет. Heise.de на этих словах ссылаются на другую свою статью, где про разблокировку фич ничего нет.
Только повторяют про обнуление SMART и переклеивание этикеток, чтобы продавать б/у по ценам новых и свежих дисков. И проясняют, что этикетки от дисков более дорогих.
Компактный режим спрятан за настройкой в about:config.
https://support.mozilla.org/en-US/kb/compact-mode-workaround-firefox
Видимо, менеджерам было невыгодно признавать ошибку. Удалить совсем - их решение. Отменить удаление - значит, показать свою ошибку. Спрятать режим - компромисс, можно лицо сохранить.
Ещё диаграмма от AMD с комментариями
*Поправки принимаются*
Вникать глубже ютубовского уровня - это значит самому поковырять FidelityFX SDK или самому подключать FSR 3 к Unreal Engine, так что сомневаюсь. Статья от Nvidia существует в виде ролика на ютубе, а статьи Techspot часто дублируют на канале Hardware Unboxed. Разве что пересказы или переводы таких материалов тут будут (или уже были).
Вместо статьи: производители видеокарт взяли алгоритмы из уплавнялок для видео, добавили информацию о движении из игрового движка (motion vectors). Плавность игр выросла, задержки (latency) тоже выросли.
Вы всё-таки или всё перепутали, или делаете невероятно сильные заявления, но в любом случае мне нужны источники. Ох, ладно - и первое, и второе, а если источник путаницы в каком-то блоге, то он ведь только для чёрного списка сгодится.
Если покороче, то вот ещё более ясный текст: "The FidelityFX Frame Interpolation technique takes 2 back buffers, and several resources shared with
FSR3UpscalerandFfxOpticalFlowto compute an interpolated image between the 2 back buffers" - FidelityFX-SDK-FSR3. Сначала два готовых отрендеренных кадра, потом генерируем кадр между ними. Никакой магии."Закрашивает получившиеся дыры" - это Inpainting в Reflex Frame Warp (та же статья на nvidia research). Только там заявляется, что кадр экстраполируется, а не интерполируется.
В Reflex 2 не заявлено рисование выстрелов и попаданий. Только "деформация кадра".
Апскейл "будущего" опорного кадра интересен тем, что если апскейл тоже надо ждать, он должен добавлять ещё несколько миллисекунд задержки.
Не готово, а ещё оптический поток (ради "particles, reflections, shadows, and lighting"), который требует 2 отрендеренных кадра (не motion vectors).
Nvidia пришлось бы опровержения не только для tomshardware писать, но и для hwcooling.net: "A major complication is that to interpolate an intermediate frame, you first need to have the previous frame and the following one available. So when using FSR 3 or DLSS 3, the game must buffer one extra frame before displaying".
Да, впрочем, Techspot смотрели на фреймген в DLSS4 в нативном разрешении - задержка тоже растёт.
Суметь без рендеринга отобразить данные, которые возникли позже последнего честно отрендеренного кадра - это ценная магия, но она ограничивается ещё не вышедшим Frame Warp.
"Reflex Frame Warp ... we explored predictive rendering; instead of always rendering from a strictly player-centered viewpoint, we extrapolate camera movement from user input" - https://research.nvidia.com/labs/adlr/DLSS4/
Думаю, если бы оно работало как "Генерация берёт старый кадр, геометрию нового кадра", то это был бы повод для гордости, сравнимый с Frame Warp (=> были бы публикации) и о нём тоже бы говорилось со словами "predictive rendering", "extrapolate". UPD: также пришлось бы публиковаться, чтобы показать прогресс по сравнению с DLSS3 и конкурентами и чтобы сообщить, что их дважды неверно поняли (опровергуть подчёркнутое): "Jensen says DLSS 4 'predicts the future' to increase framerates without introducing latency (Updated: Nope)" - tomshardware.
Это описание так ужасно расходится со словами Nvidia и бенчмарками, что очень хочется знать, откуда оно.
По Nvidia "будущий" кадр готовится целиком (рендерится и апскейлится*) а промежуточный в DLSS3 интерполируется на основе "information from the game motion vectors, the optical flow field, and the sequential game frames [т.е. предыдущего и этого "будущего" кадра]".
С бенчмарками от Techspot это сходится.
Картинки-объяснения (upd)
Если ещё порассуждать о величине задержки
"1 кадр задержки" тут в значении "1/fps", без погружения глубже, без размышлений о конвейерах.
Иллюзия магии ("задержка вывода информации уменьшается") возникает, потому что забывают про апскейл (который работает вместе с фреймгеном) и сравнивают не с DLSS-без-фреймгена, а с нативом - то есть с другим разрешением. Input Latency у Techspot под спойлером растёт относительно DLSS-без-фреймгена, как и должно быть.
Reflex по Nvidia оптимизирует render queue, чтобы кадры не скапливались и поспевали к оптимальному моменту (тут команды от CPU к более удачному моменту отложить, там частоту GPU на мгновение приподнять). Из возможностей изменения картинки заявлены только планы на будущий Reflex Frame Warp примерно как в шлемах.
* на схеме оптический поток работает с апскейленными кадрами.
Только его можно очень по-разному оверселлить. Всегда удивляли американские истории про 1.2 ТБ на месяц. В худшем случае часа три интернета. А бэкап на пару терабайт только почтой.
Это 43 мегабита в среднем.
Хотя они же этого и добивались - 10 мкФ ради минимального импеданса на этой частоте, а не ради расширения полосы пропускания вниз?
The impedance of DC Block must be very low ... DC Blocks are usually capacitors with its self-resonant frequency near operating frequency - книжка.
Мне здесь компетенций не хватает, но что-то совсем не так. Конкретному решению (поставить параллельно керамику) нужна конкретная проблема, а если опасаться чего-то неопределённого, то
это плохо кончитсязачем оставлять электролит?Если опасаться чего-то неопределённого на резонансной частоте конденсатора или за ней, то это вопрос не к электролиту, а к большому номиналу, который выбрали в vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
+ Про фортран (поведение похоже на D) и дотнет (похоже на GCC, но лучше документировано): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf#page=5
Тогда не стоит его называть
[[gnu::pure]]- этот атрибут не про гарантии от компилятора для программиста*, а наоборот - программист обещает компилятору, что функция чистая:In short, you shouldn't be saying it's pure or const if it's not pure or const
...
if the user is marking trivial functions const or pure when they clearly aren't, they deserve what they get :).
...
attributes are meant for when you are sure you know more than the compiler can tell - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Нормальные люди переименовали бы его в
[[gnu::assume_pure]]...____
* что-то такое было в D: https://dlang.org/spec/function.html#pure-functions