PlayStation 6 может стать последней консолью Марка Церни — инженер задумался о завершении карьеры

@Ilya_sss Как я и говорил, ты скатился в циклический абсурд и продолжаешь компульсивно бредить. Ну и в материально-технической части ты действительно нуль, голова лишь заскорузлыми слухами забита. Выздоравливай.

@sergeyt То что данные текут через ОЗУ это особенность операционной системы, но на ddr5 это ниочём.

Это не особенность ОС, это особенность архитектуры фон Неймана. Я написал о том, что и ЦП и ГП может обрабатывать данные с накопителя тогда и только тогда, когда эти данные будут в их памяти. PS5 способна работать с данными (распаковка, буферизация, инициализация) на этапе чтения/копирования с накопителя. А это большая разница.

По поводу скорости, у меня SSD 14600 Мбайт/сек (без компрессии) и это быстрее ПС5.

Входная скорость может быть какой угодно, но важна именно выходная. Если у тебя чтение с ssd хоть 20 ГБ/с, а сама система единовременно способна обработать в районе 3-4 ГБ/с, то как понимаешь, толку от этих 20 ГБ/с нет. Юнит ввода-вывода в PS5 должен гарантировать скорость записи данных в ОЗУ на уровне не ниже скорости чтения/копирования. То есть должна быть полная детерминированность, предсказуемость, стабильность. Сейчас очень много игр вышло с direct storage, низкоуровневая оболочка для io, но скорости чтения игровых данных всё также не поражают. 
 

@stdiomedia 10 терафлопс убогий показатель. всё остальное нюансы. и над конфой все смеялмись церни и над 10 терафлопсами это факт. не прищнавать может такое толкьо упёртый сонибой, от чего я тебе и желаю выздоравливать. аргументов я не увидел уже)) до свидание.

@Ilya_sss Реально зомби с одной извилиной. Мерзость. 

@stdiomedia 

Это не особенность ОС, это особенность архитектуры фон Неймана. Я написал о том, что и ЦП и ГП может обрабатывать данные с накопителя тогда и только тогда, когда эти данные будут в их памяти. PS5 способна работать с данными (распаковка, буферизация, инициализация) на этапе чтения/копирования с накопителя. А это большая разница.

да я и не отрицаю, что распаковка отдельной микрухой. Я о том, что на винде данные летят через озу, это особенность ос, а например линукс может ssd <-> vram, распаковкой занята видюха, для которой это стыдно задачей назвать. Понятно почему в ПС отдельная мс, чистая экономия.

Входная скорость может быть какой угодно, но важна именно выходная. Если у тебя чтение с ssd хоть 20 ГБ/с, а сама система единовременно способна обработать в районе 3-4 ГБ/с, то как понимаешь, толку от этих 20 ГБ/с нет. Юнит ввода-вывода в PS5 должен гарантировать скорость записи данных в ОЗУ на уровне не ниже скорости чтения/копирования. То есть должна быть полная детерминированность, предсказуемость, стабильность. Сейчас очень много игр вышло с direct storage, низкоуровневая оболочка для io, но скорости чтения игровых данных всё также не поражают. 

дак как раз мой ssd - тормоз, система может гораздо больше. Скорость с GDeflate ниже 23 ГБ/с не видел, даже под тридцадку видел.

@Ilya_sss системы терафлопсами сравнивать, ну на самом деле не очень уже

@sergeyt Я о том, что на винде данные летят через озу, это особенность ос, а например линукс может ssd <-> vram

ОС здесь не причём, ЦП всегда работает с ОЗУ по шине данных и адресов. По сигнальной шине принцип работы отличается. Технология peer-to-peer для прямого обмена данными, которую ты описываешь, работает и на винде, хоть через DS, хоть через устаревший win32api (но с ограничениями). Проблема в том, что данные на накопителе, хранящиеся в блочном виде, необходимо транслировать в ячейки оперативной памяти (mmu), то есть из виртуального адреса перевести в физический адрес. Для игровых данных, где необходима буферизация и инициализация, так работать не будет. Можно безбуферный поток отправить, задействовав очень большую часть пропускной способности шины, но это работать будет только для ЦП, но не для ГП. На Linux я использую "старый" и проверенный io_uring для большинства задач, но для игр его не используют разработчики, предпочитая высокоуровневый ввод-вывод данных.
 

распаковкой занята видюха, для которой это стыдно задачей назвать. Понятно почему в ПС отдельная мс, чистая экономия.

Если у тебя несколько гигабайт в секунду нужно распаковывать, то это далеко не такая простая задача и она прилично ресурсов отъедает. Благо, что это происходит в асинхронных очередях/потоках, которые скрываются от прямого доступа, поэтому не сильно бьёт по производительности. Однако минус есть, это хаотичность и созависимость самого процесса распаковки из-за его параллелизации, то есть скорость декомпрессии итоговая может очень разной. В PS5 микросхемка нужна прежде всего для эффективности, а экономия в дополнение ко всему выходит.
 

Скорость с GDeflate ниже 23 ГБ/с не видел, даже под тридцадку видел.

У тебя распаковка идёт из самой памяти ЦП/ГП, а не с накопителя. Тут твой ssd никак не может являться узким местом. На PS5 данные распаковываеются налету, по запросу (управляется это всё сопроцессорами и через контроллер прямого доступа в память) и попадают в ОЗУ уже проинициализированные и готовые к чтению. Это происходит буквально на скорости копирования с накопителя, то есть любые задержки должны быть исключены, либо вынесены в алгоритм времени обработки. 

@stdiomedia 

работает и на винде, хоть через DS, хоть через устаревший win32api

доки DS говорят через ОЗУ, скинь пожалуйста сслыку на доки, а то я не знал, что можно

на линуксе можно с ssd на видяху по dma, cpu gpu в передаче не участвуют, если данные сжатые gpu паралельно выполняет декомпрессию.

Если у тебя несколько гигабайт в секунду нужно распаковывать, то это далеко не такая простая задача и она прилично ресурсов отъедает.

в районе 5%

У тебя распаковка идёт из самой памяти ЦП/ГП, а не с накопителя.

Да
ПС5: пзу -> кракен -> озу
ПК: пзу -> озу -> (VRAM->
                              декомпрессия->VRAM)

Тут твой ssd никак не может являться узким местом.

является, остальные элементы в этой цепочке могут гораздо больше. Скорость с GDeflate от 23 до 29 у меня и она вычисляется от начала до конца операции, ну и понятно зависит от сжатия.

@sergeyt доки DS говорят через ОЗУ, скинь пожалуйста сслыку на доки, а то я не знал, что можно на линуксе можно с ssd на видяху по dma, cpu gpu в передаче не участвуют, если данные сжатые gpu паралельно выполняет декомпрессию.

Что говорят доки DS? Не совсем понял смысл написанного, но вот: https://devblogs.microsoft.com/directx/directstorage-api-downloads/
https://github.com/microsoft/DirectStorage
https://developer.nvidia.com/gpudirect-storage
Если ты надеешься включить GDS (GPU Direct Storage), то сама Nvidia эту функцию блокирует через драйвер, ОС и интерфейс здесь никакими ограничителями не являются. Нужен пропатченный kernel-модуль (на Linux имеется такая возможность). 

в районе 5%

А может и 10 и 15 и 20, многое зависит от коэффициента компрессии, общей загруженности ГП и системы в целом.
 

ПС5: пзу -> кракен -> озу

Только не Кракен, а аппаратный декомпрессор с поддержкой данного формата. Это очень приблизительная и упрощенная схема. 

ПК: пзу -> озу -> (VRAM->декомпрессия->VRAM)

А это наилучший вариант, когда видеопамяти много, но иногда распаковывать лучше всё же силами ЦП (если он что-то типа 9950x3d, как у меня), а потом копировать в видеопамять (банальная экономия).

является, остальные элементы в этой цепочке могут гораздо больше. Скорость с GDeflate от 23 до 29 у меня и она вычисляется от начала до конца операции, ну и понятно зависит от сжатия.

Проверить это легко. Смени версию pcie на 4.0 и посмотри насколько упала скорость распаковки. Степень компрессии не меняй. Если разница в пару гигабайт, то не является, а узкое место как раз сама скорость декомпрессии. Но учитывая указанный тобой разлёт в 6 ГБ/с, проблема именно программного толка. 

 

@stdiomedia 

Что говорят доки DS? Не совсем понял смысл написанного, но вот: https://devblogs.microsoft.com/directx/directstorage-api-downloads/ https://github.com/microsoft/DirectStorage https://developer.nvidia.com/gpudirect-storage

а ну вот, мы одни доки смотрим там и написано что при любом сценарии поток через озу идет, просто это настолько незначительные накладные расходы, что о них особо не вспоминают.

А может и 10 и 15 и 20, многое зависит от коэффициента компрессии, общей загруженности ГП и системы в целом.

больше восьми точно небыло не когда, да и сам прикинь игра использует 13ГБ VRAM, за какое время заполнится память.

Только не Кракен, а аппаратный декомпрессор с поддержкой данного формата. Это очень приблизительная и упрощенная схема. 

ок. А у микросхемы есть название какое то, например было бы прикольно IC BFG1)

А это наилучший вариант, когда видеопамяти много, но иногда распаковывать лучше всё же силами ЦП (если он что-то типа 9950x3d, как у меня), а потом копировать в видеопамять (банальная экономия).

Ну тут уж на совести програмистов. Надо кстати попробовать тесты через цп погонять, какая скорость будет, а то цп нагружается у меня в двух вариантах, когда расчёты мкэ выполняются и шейдеры компилируются, в 100% улетает). В играх процентов 20, точно не помню вроде в horizon больше 30 держался.

Проверить это легко. Смени версию pcie на 4.0 и посмотри насколько упала скорость распаковки. Степень компрессии не меняй. Если разница в пару гигабайт, то не является, а узкое место как раз сама скорость декомпрессии. Но учитывая указанный тобой разлёт в 6 ГБ/с, проблема именно программного толка. 

в другом слоте стоит ssd 7GB/s PCIe 4x4 в районе 11 ГБ/с показывает

если бы ssd мог 40 ГБ/с, то теоретически было бы 50ГБ/с, потому-что был бы ограничен пропускной способностью шины, но и видяхе бы поплохело

@sergeyt почему не очень? архитектура то по сути одинаковая. это вот если бы совсем разная была другое дело, а тут просто одинаковая, просто одни зажались на нормакльный чип, а другие нет.

@Ilya_sss#

@sergeyt почему не очень? архитектура то по сути одинаковая. это вот если бы совсем разная была другое дело, а тут просто одинаковая, просто одни зажались на нормакльный чип, а другие нет.

Например не всегда большее количество медленных вычислительных блоков лучше меньшего кол-ва но быстрых, первые  могут просто простаивать.

@sergeyt а ну вот, мы одни доки смотрим там и написано что при любом сценарии поток через озу идет, просто это настолько незначительные накладные расходы, что о них особо не вспоминают.

Потому что запрос на чтение/копирование и выборку делает ЦП. Но самая суть, что RTX IO, которое Nvidia обещала, а MS на это рассчитывала, она же в итоге и заблокировала на уровне драйвера, хотя у них есть для этого софт. Довольно странное решение, те же текстурные карты можно было бы без проблем напрямую через контроллер DMA в память копировать с накопителя.

ок. А у микросхемы есть название какое то, например было бы прикольно IC BFG1)

Она же интегрирована в SoC, а точнее в сам блок ввода-вывода, над названием явно не думали.

Надо кстати попробовать тесты через цп погонять, какая скорость будет, а то цп нагружается у меня в двух вариантах, когда расчёты мкэ выполняются и шейдеры компилируются, в 100% улетает). В играх процентов 20, точно не помню вроде в horizon больше 30 держался.

От имплементации самой системы ввода-вывода в движке зависит. Обёртка лишь снимает ограничения ОС, снижает накладные расходы на ЦП и задействует многопоточность. Если процессор быстрый и производительный, то разницы большой не будет. В играх, по крайней мере, потому что там созависимостей существенно больше, чем в любой синтетике.

в другом слоте стоит ssd 7GB/s PCIe 4x4 в районе 11 ГБ/с показывает если бы ssd мог 40 ГБ/с, то теоретически было бы 50ГБ/с, потому-что был бы ограничен пропускной способностью шины, но и видяхе бы поплохело

Хм, понял тебя. В теории может быть и под 50 ГБ/с при декомпрессии, но это в пике. Интервал между минимальным значением и максимальным бы увеличился. Короче, чисто для интереса оно прикольно поковыряться, но в играх таких скоростей не будет в ближайшем будущем, да они и не нужны.

 

@sergeyt Например не всегда большее количество медленных вычислительных блоков лучше меньшего кол-ва но быстрых, первые  могут просто простаивать.

Именно. У графических чипов обеих консолей идентичный дизайн из 4 шейдерных массивов. Толку от того, что в Xbox Series X увеличили количество вычислительных блоков на массив, не много. Если же обратиться к закону Амдала, то в случае, когда задача разделяется на несколько подпрограмм и частей, то общее суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного её фрагмента. 

@stdiomedia 

Но самая суть, что RTX IO, которое Nvidia обещала, а MS на это рассчитывала, она же в итоге и заблокировала на уровне драйвера

Я как понял они это эксклюзивно для цод сделали, надо же видяхи за оверлямы продавать)

но в играх таких скоростей не будет в ближайшем будущем, да они и не нужны.

вот полностью согласен. В компе несколько ssd стоит, покупал в разное время, и специально материнку покупал с pcie 5x8 под ssd, ну и сам ссдишник, в реальности я разницы вообще не вижу по pcie4 или по pcie5 игра ходит, единственное ожидание это компиляция шейдеров)

@sergeyt ага, скажите это видеокартам, где чем больше терафлопс тем быстрее она работает. 

@sergeyt Я как понял они это эксклюзивно для цод сделали, надо же видяхи за оверлямы продавать)

Единственное логическое объяснение. Хуанг тот ещё гад. 
 

единственное ожидание это компиляция шейдеров)

Ну, это основной бич всех ПК игр. 
 

@Ilya_sss#

@sergeyt ага, скажите это видеокартам, где чем больше терафлопс тем быстрее она работает. 

я не умею с видяхами разговаривать 

чем больше терафлопс

тем больше терафлопс

в растеризации сонька пошустрее будет, в шейдинге бокс и рэйтрэйсинг вроде тоже

@sergeyt я не умею с видяхами разговаривать

Это было хорошо.