Видимо, менеджерам было невыгодно признавать ошибку. Удалить совсем - их решение. Отменить удаление - значит, показать свою ошибку. Спрятать режим - компромисс, можно лицо сохранить.
точно объяснить как это всё работает? Я смотрю, пока всё это на уровне "я на ютубе смотрел"
Вникать глубже ютубовского уровня - это значит самому поковырять 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 дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
У нас здесь аналог пассивного щупа осциллографа (впрочем, несогласованного). И по тем же причинам, по которым в щупах "крокодил" земли меняют на короткую пружину, лучше максимально уменьшить расстояние (или площадь петли) как на картинке. (заметки по теме: rohde-schwarz, stackexchange[1][2])
Вообще начинание-то прекрасное и прекрасно, как vhs-decode снижает стоимость качественной оцифровки. И здесь нет никакого шок-контента, от которого могли бы кадры с полями в голове перепутаться (это к началу ветки).
Ну, среди свободных / бесплатных знаю родной ffmpeg'овский (-vcodec jpeg2000) и сторонний OpenJPEG (-vcodec libopenjpeg). Сторонний декодер был ещё медленнее и его удалили в 2023 в рамках решения оставлять только собственные декодеры их при наличии. Энкодер оставили.
Документация пропитана презрением - родной энкодер более-менее задокументирован только на сайте, а сторонний, наоборот, там не упоминается и не имеет описания параметров в хелпе или исходниках.
В lossless-режиме по степени сжатия оба не обгоняют png (медленный пресет выставил бы, если бы его можно было настроить). Из одного крупного бенчмарка lossless-кодеков его выкинули, не впечатлившись результатами (какой именно кодек - не знаю, но явно не платный).
______
Про Motion JPEG 2000 - до этого знал только про применение в кино, его там в DCP используют.
Ещё есть jpeg2000/wavelet, не делающий jpeg-артефактов
У него видится фатальный недостаток.
ffmpeg у меня декодирует его в 15 раз медленнее, чем jpeg92. ffmpeg -hide_banner -benchmark -i test.jp2 -f null - 1.5 секунды vs 100 мс на десяти мегапикселях. FastStone Image Viewer задумывается на 3 секунды. А теперь перенесёмся в нулевые...
Ускорять платным декодером - спасибо. Ускорять с потерей качества - тоже (впрочем, ускоренное подмножество выделили в 2019 - HTJ2K).
Потом ещё был гугловский jpegli, который выше оценивали. Там и декодер доработанный, и опциональное улучшение в энкодере, завязанное на встраивание ICC-профиля.
Посмотрел свою последнюю ссылку - в небольшом тесте на 4 картинках с этой опциональной возможностью он бьёт вообще всех, кроме JXL. Наверное, потому что лишь 4 картинки и 1 метрика без субъективных сравнений и детального перебора настроек, но всё равно впечатляет.
Компактный режим спрятан за настройкой в 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
Если это в виде совета переписать, будет так?
У нас здесь аналог пассивного щупа осциллографа (впрочем, несогласованного). И по тем же причинам, по которым в щупах "крокодил" земли меняют на короткую пружину, лучше максимально уменьшить расстояние (или площадь петли) как на картинке.
(заметки по теме: rohde-schwarz, stackexchange[1][2])
Картинки
Вообще начинание-то прекрасное и прекрасно, как vhs-decode снижает стоимость качественной оцифровки. И здесь нет никакого шок-контента, от которого могли бы кадры с полями в голове перепутаться (это к началу ветки).
Фракталы для сжатия - не знаю, в мейнстрим такое не попало (и даже вейвлеты после JPEG2000 - где они?).
Но зато сжатие для фракталов... то есть в JPEG XL есть мощный режим (в основном для lossless), с помощью которого можно фрактал нарисовать.
картинка
Ну, среди свободных / бесплатных знаю родной ffmpeg'овский (
-vcodec jpeg2000) и сторонний OpenJPEG (-vcodec libopenjpeg). Сторонний декодер был ещё медленнее и его удалили в 2023 в рамках решения оставлять только собственные декодеры их при наличии. Энкодер оставили.Документация пропитана презрением - родной энкодер более-менее задокументирован только на сайте, а сторонний, наоборот, там не упоминается и не имеет описания параметров в хелпе или исходниках.
В lossless-режиме по степени сжатия оба не обгоняют png (медленный пресет выставил бы, если бы его можно было настроить). Из одного крупного бенчмарка lossless-кодеков его выкинули, не впечатлившись результатами (какой именно кодек - не знаю, но явно не платный).
______
Про Motion JPEG 2000 - до этого знал только про применение в кино, его там в DCP используют.
У него видится фатальный недостаток.
ffmpeg у меня декодирует его в 15 раз медленнее, чем jpeg92.
ffmpeg -hide_banner -benchmark -i test.jp2 -f null -1.5 секунды vs 100 мс на десяти мегапикселях. FastStone Image Viewer задумывается на 3 секунды. А теперь перенесёмся в нулевые...
Ускорять платным декодером - спасибо. Ускорять с потерей качества - тоже (впрочем, ускоренное подмножество выделили в 2019 - HTJ2K).
Потом ещё был гугловский jpegli, который выше оценивали. Там и декодер доработанный, и опциональное улучшение в энкодере, завязанное на встраивание ICC-профиля.
Посмотрел свою последнюю ссылку - в небольшом тесте на 4 картинках с этой опциональной возможностью он бьёт вообще всех, кроме JXL. Наверное, потому что лишь 4 картинки и 1 метрика без субъективных сравнений и детального перебора настроек, но всё равно впечатляет.
Скрытый текст