Цитата в тему: "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]]...
в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться)
Нет, некоторые считают, что кроличья нора должна быть глубже.
"2. tapping RF off of pickup rather than internal RF test point (avoids 90s era amplification circuitry)" - forum.lddb (это про аналогичный проект с лазердисками).
Что? Мы словно с передачи RF-сигнала на импульсные БП перескочили. Там бы керамика была ultra-low-ESR/ESL дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
* через файловый менеджер, то есть.
Ещё есть некоторая драма с интерфейсом в 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
Нет, некоторые считают, что кроличья нора должна быть глубже.
"2. tapping RF off of pickup rather than internal RF test point (avoids 90s era amplification circuitry)" - forum.lddb (это про аналогичный проект с лазердисками).
Что? Мы словно с передачи RF-сигнала на импульсные БП перескочили. Там бы керамика была ultra-low-ESR/ESL дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
upd: Ещё BD пророчили более светлое будущее - в ~2014 стандартизировали* двусторонний BD-R на 200 ГБ с 3 слоями на сторону.
* White Paper - Blu-ray Disc Format - General - 4th Edition