Ростислав Михеев - Эффективное использование GPU на примере разработки игр
HTML-код
- Опубликовано: 5 окт 2024
- Подробнее о конференции C++ Russia: jrg.su/W8skjE
- -
В докладе описываются общие моменты анализа и эффективного использования современного графического процессора на примере компьютерных игр. Профилирование и оптимизация для GPU. Разбор методик из геймдева для повышения производительности.
Скачать презентацию с сайта С++ Russia - jrg.su/O0vPkF
![[Limbus Company - PV] Chapter.7 - Oblivion](http://i.ytimg.com/vi/VUpkXPkvoxU/mqdefault.jpg)
Спасибо за доклад!
Никаких куда-ядер в железе нет. Их когда-то придумала нвидия чтобы в своих рекламных агитках объяснять почему гпу лучше. А гпу есть такие ядра как в цпу, количество их примерно такое же. Единственное что гпу использует явный параллелизм и управлением им, а в цпу всё это скрыто за слоями легаси-isa и дремучих представлений о железе.
Понятие куда-ядра не просто не имеет смысла, но ещё и постоянно путает людей. О чём автор доклада частично сообщает. цпу-ядра предполагают независимый параллелизм - это значит, что мы можем абсолютно различный код исполнять на разных потоках. Аналогичные ядра(и то что мы вообще называем ядрами) в гпу есть это sm и их аналоги.
Понятие simt так же создано рекламными агитками нвидии. Оно ничем не отличается от simd и призвано разграничить в головах потребителя эти подходы. Потому как если таким же образом как нвидия считать "ядра" в цпу, то их там так же тысячи. Но лучше продолжать думать о том что цпу такой немощный.
Разницу simt нвидия пытается определять через всякие программно-аппаратные костыли. Мы не знаем насколько они аппаратный потому что нвидия максимально закрыта. Это по-сути отдельный компьютер наружу которого торчит api и что там и как исполняется мы не знаем. Он исполняет другой код совершенно, а не тот что в него посылается. Ну точно так же как x86. В последних итерациях нвидия вообще пытается вынести всю реализацию на внутренние цпу-ядра.
Обычно все эти "simt" мы реализовывали сверху точно так же как автор говорил про ифдефы и конфигурацию при компиляции. Но в современных симд(avx512) есть маски и прочая атрибутика simt. Теоретика это можно сделать эффективнее чем реализовывать это руками, но во многом эта эффективность обусловлена проблемами x86, а таких проблем в гпу нет. Проблемы х86 можно свести к следующему "процессор может исполнять больше инструкций чем читать/разбирать".
Спасибо за интерес к моему докладу, и развернутый комментарий. Мой доклад про игры и конечно далек от CUDA как от технологии, поэтому когда в каких-то моментах я упоминаю CUDA ядра то исключительно опираясь на спецификацию нвидии по архитектуре их GPU, в которой они обозначены именно как "CUDA cores" что отсылает нас к самой абривиатуре Compute Unified Device Architecture. И Nvidia и AMD действительно породили большое число различных названий для объяснения своих архитектур, в которых действительно порой легко запутаться, но если абстрагироваться от конкретных решений, можно проследить явную схожесть архитектур. Так что в тут исходя из желания абстрагироваться от конкретного производителя железа и дать общее понимание я в большей степени всегда подразумеваю ALU.
вейвы и их аналогии это и есть то, что исполняется на реальном ядре. И обмен информации там есть(как радуется автор на 50 минуте) как раз таки именно потому, что они есть часть одного целого. Это я всё к чему, а тому что цпу и гпу мало чем отличаются друг от друга несмотря на то как пытается представить это нвидия. Да, культура разная. Представление о железе в цпу-мире дремучие. Но понимание того/иного позволяет эффективно писать код на обоих устройствах.
Тема доклада довольно обширна на самом деле, и пожалуй избыточна для того чтобы уместить ее в час, поэтому местами не хватает конкретики и некоторые вещи могут показаться слишком субмурными. Но да, все так как вы пишите, некоторые операции внутри "варпа" обеспечивают высокую скорость именно потому что выполняються на железе которое физически находится рядом, и нет необходимости лезть в "дальнюю память".
@@hacenator Операции внутри вейва - их не существует. Вейв по-сути и есть инструкция, которую выполняет гпу прямо или косвенно. Поэтому они быстрые. Будь там одна и все инструкции это выполняется за одно и тоже время. Примерно как симд.
Проблемы с локальностью при доступе к памяти обусловлены тем, что вейв условно делает одно общее чтение, которое потом делится. Поэтому если мы заходит в рамках него для каждой наблюдаемой инструкции читать разные куски памяти - это просто породит больше чтений.