Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. BF6 у меня жрёт около 12–15 гб vram (а там нет лучей) и без апскейла от силы выдаёт 40–50 fps, Deadloop с лучами вообще сожрал 28, хотя есть подозрение что кое‑кто просто плохо оптимизировал его. И плюс система сама по себе 3–4 Гб VRAM отъедает.
В теории если/когда в игры начнут впихивать локальные LLM (чтобы сделать NPC менее тупыми болванчиками, например) — там да, неплохо иметь запас дополнительных 15–30 гб. Но это не про сегодня.
Сам сталкивался с подобной проблемой когда в C# делал универсальную структуру для хранения векторов и скаляров. Структура имела размер 64 байта и должна была хранить длину вектора, тип элементов и сами значения. Проблема возникла с типом decmial, который весит 16 байт и в количестве 4 штуки занимает всё место.
Выкрутился так
Поля с размером и типом впихнул в 1 байт и разместил его там, где у decimal всегда нули. Да, у этого типа реально некоторые биты ВСЕГДА равны нулю. После этого извратил хранение длины и типа так, чтобы при длине 4 и типе decimal этот байт был всегда равен нулям. Профит: при хранении других типов (которые 8 байт и меньше) данные до туда не доходят из‑за ограничений по длине, а при четырёх decimal хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Насколько я понял, это не то. Это просто полупрозрачный монитор с чёрным фоном, и непрозрачность чёрных пикселей не регулируется. То есть тут, грубо говоря, альфа‑канал равен (R+G+B)/2+0.5, и не является отдельным независимым каналом. Бабочку с картинки оно не покажет. По факту тут это реализовано полупрозрачным зеркалом, в котором отражается лежащий на столе обычный непрозрачный монитор.
Я говорю о дисплее, где у каждого пикселя своя независимая непрозрачность и свой независимый цвет. И непрозрачность не зависит от цвета.
Ну, когда‑нибудь они поймут, что прозрачные дисплеи должны уметь показывать чёрный цвет (то есть быть полноценным RGBA, а не A = R+G+B), тогда эта штука не будет снижать практичность. Но пока что никто не спешит это делать.
вертикальный лазер изготовлен с использованием литографического процесса и может быть протестирован на пластине независимо от головки
Хм, в теории это можно использовать для создания голографических дисплеев. Отклонять луч можно либо MEMS зеркалами, которые можно тут же разместить, либо фазой, но это уже более отдалённые перспективы.
Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Касательно лага — у себя практически не наблюдал, напротив у меня при восроизведении видео с Jellyfin клиента — подсветка обгоняет картинку) Поэтому и добавил параметры задержки.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
А HDR должен автоматически конвертироваться в SDR через MediaProjection API (8-битный RGBA_8888).
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(
Интересно узнать, как обстоят дела с лагом и FPS, а также с HDR — оно там по‑настоящему его обрабатывает или в SDR переводит? То есть именно сам процесс быстрого захвата картинки и анализа. Сам использую DIY подсветку на ПК, были мысли перенести анализ картинки из ПК в сами экраны, но неясно насколько хорошо это будет работать, и стоит ли результат всех танцев с бубном.
Nvidia одно время пыталась это реализовать в виде VXGI, но не взлетело. В изначально воксельных играх (типа Minecraft) это работает.
В остальных случаях приходится одновременно держать в памяти воксельное и обычное представления мира и синхронизировать их. Это кушает память, ресурсы и генерирует потенциальные баги.
Тупые численные методы со временем почти всегда побеждают более хитрые сложные алгоритмы, как только появляются соответствующие вычислительные мощности.
Только вот имхо, трасировка пути — это уже настоящее, а будущее — это нейрорендеринг, а потом и комплексный нейросинтез развлечений в реальном времени под индивидуальные предпочтения. Когда игра сможет для каждого человека индивидуально придумать историю, атмосферу, антураж, персонажей, ситуации, диалоги и прочее по его — игрока — предпочтения. А графика отойдёт на второй план, с ней уже почти все проблемы решены.
Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Тетрахромат Кончетта Антико рисует картины, на которых изображает обычными цветами то, что видит сама глазами
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 10-битного режима цветности.
Там сначала выбираешь небольшой участок изображения, на котором отчётливо видно, как размыт какой‑либо объект. По этому участку оно вычисляло ядро свёртки, по которому, с его точки зрения, было размыто изображение. Причём, нехилого такого размера — можно и 300×300 пикселей сделать. Это могло быть и радиальное размытие, и размытие в движении, даже по сложной траектории, а не просто по прямой. Ещё, по‑моему, можно было загрузить своё ядро из картинки.
И вот далее по этому ядру свёртки оно пыталось деблюрить картинку. В принципе работало, но не то что бы прям хорошо. На 4 с минусом.
Была ещё фишка, что для разных участков картинки можно было указать/вычислить разное ядро, и оно к разным частям применяло разный деблюр, плавно переходя от одного ядра к другому.
Хотелось бы увидеть сравнение результатов при разрядности 8, 16 и fp32 бит на канал. И что будет, если заблюренная картинка будет предварительно закодирована в JPEG и снова открыта. Потому что из RAW, даже с шумом, вытаскивать исходные данные куда проще, чем из перешакаленного JPEG/H264 с кубиками.
Тут суть имхо не в GIMPе, а в разложении деблюра на простейшие операции с изображением. Такое можно поворачивать и в фотошопе, и в Nuke, и в AfterEffects и другом софте.
Например, этот метод можно превратить в шейдер и деблюрить видео в реалтайме и/или больших разрешениях. Для современной видеокарты такие операции — пыль. Плюс его можно впихивать во всякие ПЛИС и контроллеры с дефицитом вычислительных ресурсов.
Для обычных ситуаций сейчас конечно лучше использовать нейронки, ещё лучше — граф из нейронок в каком‑нибудь ComfyUI. Практика показывает, что наилучшие результаты происходят при комбинации традиционного подхода и нейронок. Но такая комбинация требует танцев с бубном.
Бессмысленно сравнивать это, слишком разная архитектура. Если упростить, у яблок скорость достигается за счёт очень тесной интеграции компонентов — всё рядом. У обычного компа память/шины/gpu и прочие штуки больше архитектурно удалены друг от друга, но а) масштабируются б) могут быть сильно больше и/или мощнее.
Поэтому в одних задачах да, оно лучше, в других задачах — нет, оно хуже. Это примерно как сравнивать хороший спорткар и хороший трактор.
Глядя на современные тенденции про «а давайте все вайбкодить» и «1 инженер 1 месяц 1 миллион строк кода» я боюсь, что деланье каждого пикселя <div>ом может стать нормой в ближайшем будущем. «Мы не в 80х, зачем экономить вычислительные ресурсы» и вот это всё.
С одной стороны да, если это эффективнее решает задачу, то почему нет. Именно благодаря этому подходу мы сейчас не пишем всё на ассемблере.
С другой стороны качество софта нынче летит в пропасть, и даже на топовом железе всё работает плохо и тормозит. И однажды кто‑нибудь сделает такое не <div>ах, а на виртуальных машинах, где на каждом пикселе будет стоять отдельная винда и менять цвет обоев.
Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. BF6 у меня жрёт около 12–15 гб vram (а там нет лучей) и без апскейла от силы выдаёт 40–50 fps, Deadloop с лучами вообще сожрал 28, хотя есть подозрение что кое‑кто просто плохо оптимизировал его. И плюс система сама по себе 3–4 Гб VRAM отъедает.
В теории если/когда в игры начнут впихивать локальные LLM (чтобы сделать NPC менее тупыми болванчиками, например) — там да, неплохо иметь запас дополнительных 15–30 гб. Но это не про сегодня.
А как же мозг?
Получил огромное удовольствие, спасибо!
Сам сталкивался с подобной проблемой когда в C# делал универсальную структуру для хранения векторов и скаляров. Структура имела размер 64 байта и должна была хранить длину вектора, тип элементов и сами значения. Проблема возникла с типом decmial, который весит 16 байт и в количестве 4 штуки занимает всё место.
Выкрутился так
Поля с размером и типом впихнул в 1 байт и разместил его там, где у decimal всегда нули. Да, у этого типа реально некоторые биты ВСЕГДА равны нулю. После этого извратил хранение длины и типа так, чтобы при длине 4 и типе decimal этот байт был всегда равен нулям. Профит: при хранении других типов (которые 8 байт и меньше) данные до туда не доходят из‑за ограничений по длине, а при четырёх decimal хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Там регулируется прозрачность всего монитора целиком, а не каждого пикселя в отдельности.
Вот грубо говоря под слоем светодиодов должен быть слой вот такой вот плёнки, и под каждым пикселем свой независимый сектор. Я это имею в виду.
Насколько я понял, это не то. Это просто полупрозрачный монитор с чёрным фоном, и непрозрачность чёрных пикселей не регулируется. То есть тут, грубо говоря, альфа‑канал равен (R+G+B)/2+0.5, и не является отдельным независимым каналом. Бабочку с картинки оно не покажет. По факту тут это реализовано полупрозрачным зеркалом, в котором отражается лежащий на столе обычный непрозрачный монитор.
Я говорю о дисплее, где у каждого пикселя своя независимая непрозрачность и свой независимый цвет. И непрозрачность не зависит от цвета.
Ну, когда‑нибудь они поймут, что прозрачные дисплеи должны уметь показывать чёрный цвет (то есть быть полноценным RGBA, а не A = R+G+B), тогда эта штука не будет снижать практичность. Но пока что никто не спешит это делать.
Хм, в теории это можно использовать для создания голографических дисплеев. Отклонять луч можно либо MEMS зеркалами, которые можно тут же разместить, либо фазой, но это уже более отдалённые перспективы.
Спасибо за информацию!
Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(
Интересно узнать, как обстоят дела с лагом и FPS, а также с HDR — оно там по‑настоящему его обрабатывает или в SDR переводит? То есть именно сам процесс быстрого захвата картинки и анализа. Сам использую DIY подсветку на ПК, были мысли перенести анализ картинки из ПК в сами экраны, но неясно насколько хорошо это будет работать, и стоит ли результат всех танцев с бубном.
Nvidia одно время пыталась это реализовать в виде VXGI, но не взлетело. В изначально воксельных играх (типа Minecraft) это работает.
В остальных случаях приходится одновременно держать в памяти воксельное и обычное представления мира и синхронизировать их. Это кушает память, ресурсы и генерирует потенциальные баги.
Тупые численные методы со временем почти всегда побеждают более хитрые сложные алгоритмы, как только появляются соответствующие вычислительные мощности.
Только вот имхо, трасировка пути — это уже настоящее, а будущее — это нейрорендеринг, а потом и комплексный нейросинтез развлечений в реальном времени под индивидуальные предпочтения. Когда игра сможет для каждого человека индивидуально придумать историю, атмосферу, антураж, персонажей, ситуации, диалоги и прочее по его — игрока — предпочтения. А графика отойдёт на второй план, с ней уже почти все проблемы решены.
Поисковые системы отчуждают память, ИИ отчуждает мышление
Предположу, что существуют разные тетрахроматы с разным спектром чувствительности четвёртой колбочки.
Так или иначе, то, что у обычных людей сливается в один цвет, тетрахроматы способны видеть как отдельные оттенки. Что‑то типа биологического 10-битного режима цветности.
А ещё в фотошопе была функция Camera Shake Reducion, предназначенная для удаления смаза с фоток.
Там сначала выбираешь небольшой участок изображения, на котором отчётливо видно, как размыт какой‑либо объект. По этому участку оно вычисляло ядро свёртки, по которому, с его точки зрения, было размыто изображение. Причём, нехилого такого размера — можно и 300×300 пикселей сделать. Это могло быть и радиальное размытие, и размытие в движении, даже по сложной траектории, а не просто по прямой. Ещё, по‑моему, можно было загрузить своё ядро из картинки.
И вот далее по этому ядру свёртки оно пыталось деблюрить картинку. В принципе работало, но не то что бы прям хорошо. На 4 с минусом.
Была ещё фишка, что для разных участков картинки можно было указать/вычислить разное ядро, и оно к разным частям применяло разный деблюр, плавно переходя от одного ядра к другому.
Хотелось бы увидеть сравнение результатов при разрядности 8, 16 и fp32 бит на канал. И что будет, если заблюренная картинка будет предварительно закодирована в JPEG и снова открыта. Потому что из RAW, даже с шумом, вытаскивать исходные данные куда проще, чем из перешакаленного JPEG/H264 с кубиками.
Тут суть имхо не в GIMPе, а в разложении деблюра на простейшие операции с изображением. Такое можно поворачивать и в фотошопе, и в Nuke, и в AfterEffects и другом софте.
Например, этот метод можно превратить в шейдер и деблюрить видео в реалтайме и/или больших разрешениях. Для современной видеокарты такие операции — пыль. Плюс его можно впихивать во всякие ПЛИС и контроллеры с дефицитом вычислительных ресурсов.
Для обычных ситуаций сейчас конечно лучше использовать нейронки, ещё лучше — граф из нейронок в каком‑нибудь ComfyUI. Практика показывает, что наилучшие результаты происходят при комбинации традиционного подхода и нейронок. Но такая комбинация требует танцев с бубном.
Бессмысленно сравнивать это, слишком разная архитектура. Если упростить, у яблок скорость достигается за счёт очень тесной интеграции компонентов — всё рядом. У обычного компа память/шины/gpu и прочие штуки больше архитектурно удалены друг от друга, но а) масштабируются б) могут быть сильно больше и/или мощнее.
Поэтому в одних задачах да, оно лучше, в других задачах — нет, оно хуже. Это примерно как сравнивать хороший спорткар и хороший трактор.
Глядя на современные тенденции про «а давайте все вайбкодить» и «1 инженер 1 месяц 1 миллион строк кода» я боюсь, что деланье каждого пикселя <div>ом может стать нормой в ближайшем будущем. «Мы не в 80х, зачем экономить вычислительные ресурсы» и вот это всё.
С одной стороны да, если это эффективнее решает задачу, то почему нет. Именно благодаря этому подходу мы сейчас не пишем всё на ассемблере.
С другой стороны качество софта нынче летит в пропасть, и даже на топовом железе всё работает плохо и тормозит. И однажды кто‑нибудь сделает такое не <div>ах, а на виртуальных машинах, где на каждом пикселе будет стоять отдельная винда и менять цвет обоев.