vasyalus, вообще-то старый Cry-Engine был CPU-bound в первую очередь из-за способов вызова DX9 функций, где сам DX9 не был особо быстр, особенно на вызовах Draw, при этом там инстансинг почему-то только для травы использовался. И вода рисовалась везде. А для генерации карты высот воды там использовалось обратное преобразование Фурье над каким-то своим частотным спектром, по аналогии с
вот этим подходом, на процессоре в текстуру размером 64х64. Я думаю, если ты понимаешь, что нужно делать для двумерного случая преобразования Фурье, то вопросы должны отпасть.
У Cryengine 5, уже нет таких проблем, хотя перенесли они воду на GPU, я не смотрел. Пока все теории про то, что ремастер использует мало потоков основаны лишь на том, что люди смотрят на один показатель - загрузку ЦП в диспетчере задач. Но по этому показателю никак нельзя понять, проблема действительно в том, что ЦПУ не успевает решать линейную задачу из-за нехватки производительности, или там есть блокировки, связанные с расчетами по внутренним ресурсам. Это, например, попытки делать ридбэки после расчетов на GPU без ожидания освобождения очереди или попытки неправильно использовать occlusion culling.
Как-нибудь дойдут руки, нужно будет провести тест на загрузку CPU, уменьшив итоговое разрешение и размеры текстур, таким образом уменьшив сложность для GPU, а сложность CPU оставив как есть. Тогда можно будет понять, каков действительно максимальный фпс по процессору.
Цитата:
|
Унифицированные шейдеры для того и придумали, чтобы они всё делали. Если мы сейчас под каждую задачу будет свои блоки делать, то вернёмся к тому, от чего ушли во времена 8800 GTX. За трассировкой на потоковых процессорах будущее.
|
Трассировка не получит никаких плюсов, кроме замедления своей работы, от того, что будет выполняться вместо RT-ядер, на обычных вычислительных. Дело в том, что в основе трассировки лежит алгоритм поиска пересечения луча и треугольника, который в случае с RT-ядрами, выполняется на аппаратных ядрах, которые не имеют оверхеда на обработку математических команд (дешифрование команды, дешифрование сдвига программного счетчика при переходе и т.д.). Если взять какой-нибудь известный алгоритм, который позволяет получать барицентрические координаты (
например этот), и посмотреть на него, то становится очевидно, что подобное количество операций, выполняемых на универсальном программируемом устройстве просто на накладных расходах сожрет раз в 10 больше времени, чем реально потратит на математические операции внутри.
То есть еще раз, операция поиска пересечения луча с геометрией не меняется никак в зависимости от алгоритма - ты все равно получаешь в результате точку пересечения и координаты на поверхности треугольника (и сам треугольник), т.е. от программируемости этой части ты не получишь никакого выигрыша, зато тебе понадобится в 3-4 раза больше CUDA-ядер для аналогичной производительности по сравнению с чипом, в котором RT-ядра есть.
Ровно по этой же причине видеокарты оснащаются блоками растеризации и текстурными блоками. Первые вычисляют, каким пикселям экрана соответствует пришедший треугольник, а вторые обеспечивают аппаратную интерполяцию при чтении из текстуры. И вроде бы, например, для текстурных блоков есть смысл реализации своей логиики для чтения из текстуры, например, для шедоумапов (там интерполяция должна выполняться по результатам сравнения больше-меньше, а не по значению самой глубины), но тем не менее текстурные модули никто никуда не убирает. И этому есть хорошая причина - четыре чтения из текстуры с последующими тремя командами lerp гораздо медленнее, чем одно чтение из текстуры через текстурный модуль. И это если у нас один мип-уровень и линейная интерполяция, а что будет, если анизотропная 16х?
Ну и потом, я подозреваю, что люди не правильно понимают, как работают шейдеры трассировки лучей. На самом деле там максимально широкие возможности для программирования: ты сам задаешь пейлоад для луча (данные, которые будет можно менять при каждой регистрации попадания луча в препятствие), ты сам определяешь, что делать, когда луч попал во что-то (например, можно породить еще один луч с новыми данными, изменить данные в старом луче и отправить его по другому направлению, или вообще сказать, что попадания не было, если текстура в месте попадания была прозрачной, как например участки на листьях деревьев). Так что можно, конечно, сделать всё вообще программируемым, но это будет сильно дороже и сильно медленнее.