Цитата(Cossack-HD @ 15.06.2020, 19:48)
Ссыль с таймкодом на всякий случай
И там ничего нет - "мы совместно с AMD заложили обратную совместимость, и она не пропадет оттуда, как это было с PS3". Ммм, ок.
Цитата(Cossack-HD @ 15.06.2020, 19:48)
волны всё равно считаются на шейдерах
Эмм, шо?
Цитата(Cossack-HD @ 15.06.2020, 19:48)
От 2x8 или 4x4 - не важно, шейдеров одинаковое количество
Эмм, шо x2?
Ты пытаешься рандомно бросать умные термины чтоб выглядело типа "я в теме" ?
Что значит "волны всё равно считаются на шейдерах" ? Вот мне реально интересен смысл этой фразы.
"Размер волны" - это, грубо говоря, сколько шейдерных инстансов может одновременно обрабатывать потоковый процессор (CU/WGP). Умножаешь на кол-во таких процессоров - получаешь размер "сетки".
Т.е. если у нас 10 таких процессоров, и "ширина" каждого - 64 - то у нас одновременно может бегать 640 шейдерных инстансов.
Чтоб было проще - считай за раз пиксельным шейдером обрабатываются 640 пикселей.
Ок?
Что произойдет если поменять "ширину" ? - Ну особо страшного в целом ничего - кол-во одновременно считающихся шейдерных инстансов все равно будет wave_size * pu_count.
Отсюда вывод - напрямую "ширина" PU на обратную совместимость не влияет.
Зачем же тогда я про нее писал? А потому что, чтоб выжать максимум перформанса, тебе надо эти самые PU загрузить, иначе простой отдельных потоков, "пузыри воздуха", и недозагруженность GPU.
Для этого надо знать "ширину" PU - чтоб ты мог посчитать "occupancy" - т.е. сколько регистровой памяти и инструкций ты можешь затолкать в шейдер, до того как планировщику прийдется туго ибо ресурсов не будет хватать.
Особенно когда ты юзаешь compute shaders, ведь там ты сам указываешь планировщику какими "кусками" ты бы хотел запускаться (что необходимо, ибо как ты там с памятью работаешь знаешь один ты).
И вот поэтому новые WGP умеют конфигурировать свою "ширину" - чтоб старые оптимизации у PS4 тайтлов не стали анти-оптимизациями.
> От 2x8 или 4x4 - не важно, шейдеров одинаковое количествоОчень важно, ибо как-раз таки "количество шейдеров" будет разное, ибо как я писал выше - играеть сильную роль фактор "occupancy".
> Другое дело - как на них разные матаны будут выжимать разный условный IPC. Тут уже мысли о 16/32/64-bit floating pointКак раз это сильно влияет на "occupancy", ибо 16 регистры меньше памяти занимают, а значит можно более "жирные" шейдеры напихать плотненько не потеряв в загрузке.
Так что прирост производительности будет именно за счет плотности загрузки, а сам IPC (как я уже писал ранее а ты игнорировал) - будет упираться в добавленную latency.