Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Производительность при отрисовке геометрии. (3 стр)

Производительность при отрисовке геометрии. (3 стр)

Страницы: 1 2 3 4 59 Следующая »
SuslikМодераторwww7 дек. 20187:25#30
san
по-моему, ты сам себе настекал кучу неизвестных параметров и в них, разумеется, трудно разобраться. почему бы не погонять своё тестовое приложение для начала на системе с одной видеокартой и без окулуса? потому что иначе большое количество левых факторов могут блочить пайплайн.
sanПостоялецwww7 дек. 20187:43#31
Suslik
Да все и так работает на одной видеокарте. Остальные две не у дел. И чего вы все к Окулусу привязались, это просто монитор. Загрузку видеокарты видно в профайлере, рендер 600.000 вершин занимает 4-5 мс. На любой из трех карт. Драйвер Окулуса сам находит куда он подключен и стартует на соответствующей карте. На графике видно как все работает - в первом посте есть картинка, там верхняя линейка это загрузка GPU, нижняя - CPU. Видно, что CPU только запускает рендер, после чего карта работает 5 мс рисуя эти 600.000 вершин. Потом все повторяется на втором глазе. Что бы "проверить без окулуса" сложно, надо ломать всю аппликацию, но я в этом никакого смысла не вижу. Можно еще монитор поменять (а у меня их два), или блок питания... но к ИМХО работе карты это отношения не имеет
SuslikМодераторwww7 дек. 20187:48#32
san
> И чего вы все к Окулусу привязались
как чего? ты сам написал:
> рендер 600.000 вершин занимает 4-5 мс
очевидно, что на любой вменяемой видеокарте должно быть гораздо быстрее в нормальных условиях*. очевидно, что где-то есть проблема и самый простой способ её найти — отсекая источники потенциальных причин. ещё можно попробовать уменьшить разрешение главного рендертаргета до чего-то очень низкого вроде 128х128, чтобы убедиться, что дело точно не в филлрейте и не во фрагментном шейдере.

*) под "нормальными условиями" понимается среднестатический филлрейт, то есть фрагменты не слишком сильно перекрываются, тривиальный шейдинг и блендинг.

Правка: 7 дек. 2018 7:52

sanПостоялецwww7 дек. 20188:18#33
Suslik
Я отключал фрагментный шейдер (ставил нулевой), на перформанс это не влияет. Кроме того, я уже писал, что включение MSAA 4х4 почти не сказывается на скорости, тесселяция отключена, геометрического у меня вообще нет. Значит из всего конвейера остается вертексый. Но там одна строчка. Получается на скорость влияет сама обработка вершин, и возможно кеширование внутри видеокарты. Окулус никак не может влиять на это, его постпроцесс включается после того, как закончился основной рендер и занимает 1 мс на кадр. На графике это видно. Фактически у меня идет просто отрисовка треугольников, более ничего. Завтра я попробую разбить буфер на более мелкие кусочки и посмотрю что будет. Но я всегда считал, что один большой кусок лучше чем много маленьких.
MrShoorУчастникwww7 дек. 20188:49#34
san
> рендер 600.000 вершин занимает 4-5 мс.
Не может рендер 600К вершин занимать 4-5 мс. Либо у тебя ну крайне хреновый рендер, либо ты слабо себе представляешь возможности GPU. Специально для тебя записал видео.

В блендере создал кучу высокополигональных сфер. Вверху видна строка, что в кадре больше 10 миллионов вершин, и больше 20 миллионов треугольников. Рисуется это со скоростью 60 кадров в секунду (упирается в VSync). Карл! 10 миллионов в 60FPS. Я бы сделал и в 2 раза больше вершин, но блендеру плохо становится с потреблением памяти (на моей домашней машине всего 16Гб, и он выходит за эти пределы при дублировании геометрии).
Так вот, у меня видеокарта GF980. А у тебя титан с 600К вершин не справляется. Смешно же.

Поэтому я еще раз говорю, ты не туда смотришь в GPUView. Куда смотреть - я тебе показал. А еще лучше смотреть в NSight или PIX.

kasПостоялецwww7 дек. 20189:46#35
MrShoor
> Поэтому я еще раз говорю, ты не туда смотришь в GPUView. Куда смотреть - я тебе
> показал. А еще лучше смотреть в NSight или PIX.
ага, дилетантам гпувью противопоказан. ну и сам по себе упоротый - говорят четко видно синк в окулусе пробуй без и увидишь настоящую производительность - нет это надо чтото делать, телепатируйте по моей ниочем не говорящей картинке
innuendoПостоялецwww7 дек. 201810:16#36
kas
где мне купить твою игру?

SuslikМодераторwww7 дек. 201810:36#37
san
> Я отключал фрагментный шейдер (ставил нулевой), на перформанс это не влияет.
> Кроме того, я уже писал, что включение MSAA 4х4 почти не сказывается на
> скорости, тесселяция отключена, геометрического у меня вообще нет. Значит из
> всего конвейера остается вертексый. Но там одна строчка. Получается на скорость
> влияет сама обработка вершин, и возможно кеширование внутри видеокарты. Окулус
> никак не может влиять на это, его постпроцесс включается после того, как
> закончился основной рендер и занимает 1 мс на кадр. На графике это видно.
> Фактически у меня идет просто отрисовка треугольников, более ничего. Завтра я
> попробую разбить буфер на более мелкие кусочки и посмотрю что будет. Но я
> всегда считал, что один большой кусок лучше чем много маленьких.
окей, тогда попробуй сделать ещё меньше геометрии. не знаю, куб один рендерь. я ставлю на то, что всё равно 4-5мс, потому что где-то вклинивается какая-то синхронизация чего-то с чем-то. либо окулус делает какую-то свою магию. потому что не может 600к треугольников так медленно рендериться на современной видеокарте.
BingoBongoПостоялецwww7 дек. 201811:17#38
Предложение замерить фпс той же сцены, но без окулуса уже было? В ВР фпс не может быть любым. Если не ошибаюсь, максимальный фпс у окулуса 90, и он может только уменьшаться, имея фиксированные значения. Собственно, если для каждого глаза рендерить с 90 фпс, то и получим те самые 5 мс на кадр.

Правка: 7 дек. 2018 11:42

DampireУчастникwww7 дек. 201811:49#39
BingoBongo
Оно и уменьшаться по дефолту толком не может. Читайте про асинхронный/синхронный таймварп.
sanПостоялецwww7 дек. 201821:03#40
Suslik
> окей, тогда попробуй сделать ещё меньше геометрии. не знаю, куб один рендерь. я ставлю на то, что всё равно 4-5мс,
Не-а. Линейно зависит. Уже пробовал переходить на 16 битные индексы и маленькие буфера - все те же 4 мс.

BingoBongo
> Предложение замерить фпс той же сцены, но без окулуса уже было?
Я не фпс меряю, я смотрю на данные профайлера. Если общее время вылазит за 11 мс, то фпс падает вдвое, разумеется.

Меня задолбали "знатоки" GPUview, сначала хотел промолчать, но когда тебя публично называют "дилетантом" то это право обидно...
Потому некоторый ликбез, который может быть полезен MrShoor, kas и тем кто интересуется профилированием графики.
Сначала пара слов о своем бэкграунде - я два года занимался разработкой SDK для VR хедсета на уровне железа.
Плотно взаимодействовал с ребятами из AMD и с WPR и GPUview работал ежедневно. Уже 22 года я живу и работаю в Торонто.
Мимоходом могу заметить, что мой стаж програмиста наверно намного превышает возраст большинства читателей геймдева :)

Теперь посмотрим на картинку, которую дает GPUview, первая строчка:

p1_Gpuview | Производительность при отрисовке геометрии.
В левом верхнем углу написано "Adapter [AMD Radeon (TM) R9 Fury Series]" - это моя первая видеокарта, к которой подключены мониторы.
Далее две линии: "Hardware Queue 3D" и "Hadrware Queue Copy" это соответственно загрузка очереди вывода на экран и очереди копирования.
Никакой особой активности там не наблюдается, поскольку этот адаптер только показывает картинку на мониторе, аппликация запущена не на нем.
Некоторый интерес имеет строчка Copy, поскольку там показана пересылка картинки с одного адаптера на другой, но сейчас это неважно.
Да, компьютер может иметь несколько видеокарт и DX11 позволяет запустить приложение на любой из них.
DX12 может работать одновременно на нескольких адаптерах, но сейчас не об этом.
Сейчас важно понять, что это не наш адаптер и нужно смотреть ниже. Пропускаем микрософтовский эмулятор и видим вот что:

p2_Gpuview | Производительность при отрисовке геометрии.
Это уже интереснее, это как раз та карта, которая заниимается рендерингом.
Вверху написано "Adapter [NVIDIA TITAN V]" - это наш парень! Теперь смотрим что под ним:

"Hardware Queue 3D", "Video Encoder", Copy", "Graphics_1" и "Comput_1".
Ну энкодингом видео занимается окошко окулуса с рекламой, это строчки для нас не важны.
Главное тут это "Graphics_1", поскольку это основной пейплайн аппликации. Справа можно увидеть то, что MrShoor назвал "непонятными прямоугольниками".
Но это как раз самое главное! Это график загрузки видеокарты.

Каждый прямоугольник в этой строке показывает выполнение конвейером операции, т.е. работу вертексного и фрагментного шейдеров.
Две первых коротких палочки это отрисовка картинки на контрольном мониторе, для нас это интереса не представляет.
Именно после этого и запускается копирование, которое можно видеть в строчке Copy и далее на первой картинке.
Потом идут еще два прямоугольника, один короткий, второй подлиннее.
Это у меня из рук выходят два луча (типа лазера) и я определяю расстояние до подсвеченного обьекта (просто берется депт с узким фрустумом).
Первый контроллер лежит на столе и смотрит в небо, там ничего нет, потому рисовать почти нечего.
Второй контроллер я держу в руке и ему приходится обработать какое-то количество треугольников, что занимает примерно миллисекунду.
Далее идут два длинных прямоугольника, это собственно рендер сцены для левого и правого глаза. Первая линейка занимает 3 мс, вторая 4.
Почему время разное? А посмотрите ниже, там наблюдается активность на Compute_1.
Это SDK Окулуса запустил постпроцесс - компьют шейдер по коррекции искажений для предыдущего фрейма.
Все же карта у нас одна и потому рендер занял на 1 мс больше времени.
Потом идет короткая линейка - это вывод на контрольный экран, который будет показан AMD адаптером во время всинка (прямоугольник на предыдущей картинке в первой линейке справа). 
Общее время выполнения вывода всей сцены получается чуть больше 11 мс, потому следующий фрейм пропущен. Встает вопрос почему цикл начался с задержкой?
Для ответа смотрим намного ниже, там где активносты CPU:

p3_Gpuview | Производительность при отрисовке геометрии.
Это как раз то место, где MrShoor пытался определять загрузку видеокарты, но к карте это не имеет отношения. Забудем пока про красные прямоугольники, посмотрим на линейку ниже. Это работа CPU.
Сначала 2мс аппликация занимается собственными делами, потом приступает к рендерингу. Сначала идут те два луча про которые я говорил, потом запуск рендера левого глаза, затем правого.
Каждый раз процессор ждет окончания работы видеокарты, это показывает строчка выше (там показана очередь окончания операции на GPU).
В принципе я мог бы не ждать и выполнять все операции немедленно. Тогда на строчке выше появился бы такой "небоскреб" из очереди на обработку видеокартой.
В данном случае я жду и потому процессор простаивает большую часть времени. Нагрузна на CPU тут минимальная.

В первом своем посте я просто выкинул все не относящиеся к делу детали, но поскольку не все поняли что это такое, мне пришлось написать это разьяанение.
Надеюсь кому-то будет полезно.

Все вышеописанное не имеет прямого отношения к проблеме но надеюсь позволяет лучше понять как работает GPUview.

Правка: 8 дек. 2018 6:16

MrShoorУчастникwww7 дек. 201821:35#41
san
> Справа можно увидеть то, что MrShoor назвал "непонятными прямоугольниками".
Непонятный прямоугольник он потому, что ты совершенно не знаешь, что именно за команды выполняются внутри того прямоугольника. А внутри прямоугольника могут быть синхронизации, когда видеокарта не работает, а ждет. И прямоугольники - это не "нагрузка" на видеокарту. Это пакет в очереди, который ждет обработки. И по ширине прямоугольника видно сколько времени пролежал в очереди этот самый пакет. А если в пакете или перед ним есть синхронизация, то длина этого самого пакета растягивается, но это не значит, что видеокарта при этом работает.

И на строчку Hardware Queue смотреть не надо, потому что туда складывается абсолютно все (включая эти самые невидимые синхронизации), а не только то, что ты положил. Эта строчка может быть полезна разработчикам драйверов, но не тебе. Ибо только они знают, что именно они кладут в Hardware Queue.
А смотреть надо на обработку тех пакетов, которые кладешь в очередь ты, и на скорость обработки твоих пакетов. Определить их в GPUView можно по present-у, и вот тут:
Изображение
Я стрелочкой показал тебе на твои пакеты. И обработаны они были примерно за одну миллисекунду.

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

Правка: 7 дек. 2018 21:36

sanПостоялецwww7 дек. 201822:02#42
MrShoor
> Непонятный прямоугольник он потому, что ты совершенно не знаешь, что именно за
> команды выполняются внутри того прямоугольника. А внутри прямоугольника могут
> быть синхронизации, когда видеокарта не работает, а ждет.
Не может. Не надо фантазировать. Это выполнение основного конвейера из вертексного-тесселяторов-геометрического и фрагментного шейдеров.
Они выполняются одновременно в разных потоках, потому ты не можешь увидеть разблюдовку. Но это однозначно говорит о РАБОТЕ карты. Всех ее коров. Ожидание это пустое место между прямоугольниками.

>А смотреть надо на обработку тех пакетов, которые кладешь в очередь ты, и на скорость обработки твоих пакетов.
Ничего подобного. Это состояние ОЧЕРЕДИ, а не время ее обработки. У меня в очереди стоит только один пакет, потому он запускается сразу, но ВЫПОЛНЯЕТСЯ он довольно долго.
Если у тебя несколько пакетов, то они будут ждать выполнение друг друга и ты увидишь время ожидания, которое равно суммарному времени выполнения предыдущих пакетов.

И я не ДУМАЮ, я ЗНАЮ. В этом разница между нами.

Что до CPU работы, которую ты не видишь, то промотай скролл вверх. Обнаружишь Окулус сервер который и делает эту синхронизацию.
Это вывод на экран хедсета который происходит уже после того, как моя часть программы отработала. Аналог ожидания всинка.

Правка: 8 дек. 2018 5:17

MrShoorУчастникwww7 дек. 201822:20#43
san
> И я не ДУМАЮ, я ЗНАЮ. В этом разница между нами.
Так же хорошо знаешь, как когда делал сферическую проекцию через 2 поворота кватернионами, а когда я показал тебе решение на сферических координатах - удалил тему? Или чуть лучше знаешь?

Ладно, я не вижу смысла ничего тебе объяснять. Ты не вменяем походу.

sanПостоялецwww7 дек. 201823:58#44
Не работало твое "решение", что я тебе сразу и сказал. А кватернионы работают.
Просто ты постоянно вместо того что бы спокойно разобраться в задаче, сразу кидашься что-то быстро отвечать и махом решать все проблемы.
Но, как показала практика, глубоких знаний у тебя немного. А слушать других, кто разбирается в вопросе немного лучше, ты не желаешь. Сразу пытаешься учить.
Это такое очень детское поведение.
Если ты разберешся в том же GPUview ты поймешь, что ты писал бред. Я честно сказать думал, что ты сразу уберешь свои портянки, после того, как я показал тебе, что вместо GPU ты пытаешься анализировать CPU, но до тебя это так и не дошло. Холивар разводить не буду, захочешь - сам разберешься.
Страницы: 1 2 3 4 59 Следующая »

/ Форум / Программирование игр / Графика

2001—2018 © GameDev.ru — Разработка игр