Я думаю, разница в том, что код игрок не видит, а контент — видит. Я сам не против ИИ, прогресс это хорошо, но я за качество. У большинства современных нейросетей с качеством результата проблемы. Если эти проблемы фиксить перед продакшеном (опять же не важно — руками или автоматом) — вопросов нет. Но их не фиксят.
Я вот играю. Если оно будет и вправду лучше, то есть не только в техническом исполнении, но и в смысловом наполнении — то почему бы и нет.
Но тот ИИ, что у нас сейчас есть, в подавляющем большинстве случаев делает хуже. И в смысловом, и в техническом аспектах. Вот тебе нравится что‑либо, ты начинаешь присматриваться, вглядываться в детали — а вместо деталей видишь слоп. И ощущение как будто тебя кинули. Видимость качества из характеристики продукта превращается в инструмент манипуляции вниманием, и это ничего кроме негатива и разочарования не вызывает.
Дополню по функции Mosaic: на потребительских картах она тоже есть, но в ограниченном варианте и называется Surround. От 2 до 5 экранов по горизонтали или вертикали (при этом у всех либо вертикальная либо горизонтальная ориентация). Точно также единый виртуальный экран + коррекция рамок.
Дома эта штука прекрасно себя показывает в играх. Правда часто приходится долго возиться, чтобы заставить игру вменяемо работать на широком виртуальном экране.
Так для 120 Гц+ это и делается в основном. Экраны 4K 120 Гц+ уже есть давно, сейчас уже 1000 Гц вроде мелькает (правда не 4К) + кривая оптимизация современных игр и лучи кушают очень‑очень много ресурсов.
У меня, например, без этих штук карта может выдать только около 55 fps, но если подключить XeSS (DLSS не работает) + MFG, легко получается 120–160 fps, и эта плавность реально заметна.
PS. Мне кажется не решает проблему, а купирует симптомы. По потолку уже коварно ползёт очень интересная муха, которая своей интересностью может разрушить его идеальный план.
Спасибо) В целом, я думаю, Вы правы — конструкция нужна будет сильно другая, а спрос на такое пока невелик. Но возможно в будущем он появится, по крайней мере, со стороны геймеров.
Тут нет единого угла, под которым было бы удобно пользоваться всегда. Руками двигать неудобно. Использую почти для всего: программирование, графика/видео/3д, нейросети, игры (в основном шутеры) и др.
Было бы интересно скомбинировать вашу штуку с моей — сделать раскладывающееся кресло и изменение угла всей композиции в целом. То есть чтобы экраны висели не на стене, как у меня, а на едином шасси как у E-station, которое вместе с креслом могло бы менять угол относительно земли.
Управляются пультом и с компа, можно независимо, можно вручную и автоматом
3Д
Но есть сильное подозрение, что простым увеличением габаритов тут не отделаешься, так как массы тут несколько отличаются от обычных экранов.
Раньше под этим подразумевалось что‑то типа WinAPI/C++/MFC. Что сейчас подразумевается непонятно, но есть шанс что нужно будет две RTX 5090 чтобы панель задач меньше тормозила.
А есть ли заметная разница между 6 и 4 битами? Coder Next 80b пробовал только в 4 и 6 битах, 8 не пробовал. И 6 бит по уровню показались такими же, как 4 бита, даже на сложных задачах, а вот производительность там падала на дно. Видимо, рантайм был староват ещё.
Спасибо, это лучшее объяснение работы JPEG, которое я читал.
В одно время приделал у себя в софте режим просмотра YCbCr 2×2 специально чтобы ловить, что камера стала передавать пережатый видеопоток — на цветоразностных каналах артефакты вылезают даже на высоком качестве. Ну и субдискретизация сразу видна по прямоугольным пикселям. У JPEG всё это ещё слабо выраженно, видеокодеки в этом плане заметно агрессивнее.
Оригинальная картинка, яркостная компонента, синяя и красная цветоразностные. Внизу пиксели прямоугольные - камера при переключении на 1080p включила сжатие и появилась субдискретизация
Теоретически кодеки могут дойти до уровня «текст промпта генерации + номер сида + хеш весов модели», там то точно биометрии некуда будет уместиться (и то не факт:|). Но практически до этого ещё далеко, хотя, вроде бы, в H266 уже потихонечку внедряют ИИ для сжатия.
Я гонял у себя qwen 3.5 27b claude opus 4.6 distill в квантизации q4_k_m и q8. Первая даёт 60+ т/с, вторая около 14 т/с.
Фокус в том, что в задачах написания кода, поиска в нём ошибок, а так же в анализе изображений q8 показала себя заметно глупее, чем q4_k_m. Буквально. Я пока не выяснил, с чем это связано. Так что помимо самой разрядности важно чтобы сам процесс квантизации был проведён грамотно. И с этой q8 что-то пошло не так.
И будет тёмно‑серый вместо чёрного, с посаженой яркостью :)
Тогда уж лазерные ТВ стоит рассмотреть (которые на деле ультракороткофокусные лазерные проекторы), где экран из призм, и снизу выглядит белым, а снизу — чёрным. Не панацея, но лучше, чем ничего.
Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. 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 хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Я думаю, разница в том, что код игрок не видит, а контент — видит. Я сам не против ИИ, прогресс это хорошо, но я за качество. У большинства современных нейросетей с качеством результата проблемы. Если эти проблемы фиксить перед продакшеном (опять же не важно — руками или автоматом) — вопросов нет. Но их не фиксят.
Я вот играю. Если оно будет и вправду лучше, то есть не только в техническом исполнении, но и в смысловом наполнении — то почему бы и нет.
Но тот ИИ, что у нас сейчас есть, в подавляющем большинстве случаев делает хуже. И в смысловом, и в техническом аспектах. Вот тебе нравится что‑либо, ты начинаешь присматриваться, вглядываться в детали — а вместо деталей видишь слоп. И ощущение как будто тебя кинули. Видимость качества из характеристики продукта превращается в инструмент манипуляции вниманием, и это ничего кроме негатива и разочарования не вызывает.
Спасибо, не знал что такие карты ещё делают!
Дополню по функции Mosaic: на потребительских картах она тоже есть, но в ограниченном варианте и называется Surround. От 2 до 5 экранов по горизонтали или вертикали (при этом у всех либо вертикальная либо горизонтальная ориентация). Точно также единый виртуальный экран + коррекция рамок.
Дома эта штука прекрасно себя показывает в играх. Правда часто приходится долго возиться, чтобы заставить игру вменяемо работать на широком виртуальном экране.
Так для 120 Гц+ это и делается в основном. Экраны 4K 120 Гц+ уже есть давно, сейчас уже 1000 Гц вроде мелькает (правда не 4К) + кривая оптимизация современных игр и лучи кушают очень‑очень много ресурсов.
У меня, например, без этих штук карта может выдать только около 55 fps, но если подключить XeSS (DLSS не работает) + MFG, легко получается 120–160 fps, и эта плавность реально заметна.
К чему эти полумеры
PS. Мне кажется не решает проблему, а купирует симптомы. По потолку уже коварно ползёт очень интересная муха, которая своей интересностью может разрушить его идеальный план.
Спасибо) В целом, я думаю, Вы правы — конструкция нужна будет сильно другая, а спрос на такое пока невелик. Но возможно в будущем он появится, по крайней мере, со стороны геймеров.
Тут нет единого угла, под которым было бы удобно пользоваться всегда. Руками двигать неудобно. Использую почти для всего: программирование, графика/видео/3д, нейросети, игры (в основном шутеры) и др.
Было бы интересно скомбинировать вашу штуку с моей — сделать раскладывающееся кресло и изменение угла всей композиции в целом. То есть чтобы экраны висели не на стене, как у меня, а на едином шасси как у E-station, которое вместе с креслом могло бы менять угол относительно земли.
3Д
Но есть сильное подозрение, что простым увеличением габаритов тут не отделаешься, так как массы тут несколько отличаются от обычных экранов.
Раньше под этим подразумевалось что‑то типа WinAPI/C++/MFC. Что сейчас подразумевается непонятно, но есть шанс что нужно будет две RTX 5090 чтобы панель задач меньше тормозила.
Попробуйте пообщаться с теми кто делает реализации кодеков H265/H266 на SIMD/CUDA, или кто пишет ядра инференса современных LLM :)
А есть ли заметная разница между 6 и 4 битами? Coder Next 80b пробовал только в 4 и 6 битах, 8 не пробовал. И 6 бит по уровню показались такими же, как 4 бита, даже на сложных задачах, а вот производительность там падала на дно. Видимо, рантайм был староват ещё.
Может быть в этом?
Спасибо, это лучшее объяснение работы JPEG, которое я читал.
В одно время приделал у себя в софте режим просмотра YCbCr 2×2 специально чтобы ловить, что камера стала передавать пережатый видеопоток — на цветоразностных каналах артефакты вылезают даже на высоком качестве. Ну и субдискретизация сразу видна по прямоугольным пикселям. У JPEG всё это ещё слабо выраженно, видеокодеки в этом плане заметно агрессивнее.
Теоретически кодеки могут дойти до уровня «текст промпта генерации + номер сида + хеш весов модели», там то точно биометрии некуда будет уместиться (и то не факт:|). Но практически до этого ещё далеко, хотя, вроде бы, в H266 уже потихонечку внедряют ИИ для сжатия.
Я гонял у себя qwen 3.5 27b claude opus 4.6 distill в квантизации q4_k_m и q8. Первая даёт 60+ т/с, вторая около 14 т/с.
Фокус в том, что в задачах написания кода, поиска в нём ошибок, а так же в анализе изображений q8 показала себя заметно глупее, чем q4_k_m. Буквально. Я пока не выяснил, с чем это связано. Так что помимо самой разрядности важно чтобы сам процесс квантизации был проведён грамотно. И с этой q8 что-то пошло не так.
И будет тёмно‑серый вместо чёрного, с посаженой яркостью :)
Тогда уж лазерные ТВ стоит рассмотреть (которые на деле ультракороткофокусные лазерные проекторы), где экран из призм, и снизу выглядит белым, а снизу — чёрным. Не панацея, но лучше, чем ничего.
Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. 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 хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Там регулируется прозрачность всего монитора целиком, а не каждого пикселя в отдельности.
Вот грубо говоря под слоем светодиодов должен быть слой вот такой вот плёнки, и под каждым пикселем свой независимый сектор. Я это имею в виду.