Войти
ПрограммированиеФорумГрафика

Технологии эффективного рендеринга геометрии. (комментарии) (2 стр)

Страницы: 1 2
#15
22:05, 3 июля 2009

doc.
> А какова ширина фрагментов-полос?

Делал как в статье 9 вершин, делал 8 вершин, делал 32 вершины, одинакого фиолетого... (В том смысле что ФПС выше не становится, чем короче полоса - тем ниже ФПС)
Конечно возможно ландшафт 512 шириной (1024 вершины на стрип) вошёл в кеш полностью, я незнаю каких размеров щас кеши... :)


#16
22:23, 3 июля 2009

Думаю сейчас производительность очень велика и чтоб почувствовать кэш нужен очень тяжелый вершинный шейдер. Попробуй какую-нибудь тяжелую "синтетику" сварганить.

#17
0:03, 4 июля 2009

doc.
> Думаю сейчас производительность очень велика и чтоб почувствовать кэш нужен
> очень тяжелый вершинный шейдер. Попробуй какую-нибудь тяжелую "синтетику"
> сварганить.

Нагрузил вершинный по самое не балуйся:

28-29 ФПС без оптимизации (ширина 512 количество вершин)
37-38 ФПС с оптимизацией, более менее оптимальным ширина полосы оказалась 64 (количество вершин)

Чот не айс всё равно...

#18
0:11, 4 июля 2009

Executor
> Чот не айс всё равно...
+30% производительности не айс? :)
ботелнек возможно еще в чем-то другом...

#19
0:25, 4 июля 2009

doc.
> +30% производительности не айс? :)
> ботелнек возможно еще в чем-то другом...

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

Единственное чего не пойму, почему ширина должна быть аж 64? Это 128 вершин! Неужели они все в кеше?

#20
10:40, 4 июля 2009

Executor
Можешь смеяться, но мне что-то подсказывает, что если камеру помести вблизь поверхности, много треугольников не обрезать, а это различные РПГ от первого лица.

Потом, видел формат моделей в Warcraft 3? Там все текстуры используются по максимальному числу раз, мне что-то подсказывает, что это сделано для того, чтобы отрисовывать модели с одинаковыми текстурами за один раз. И я до сих пор не могу понять, как пользоваться текстурными атласами на стрипованной геометрии не используя шейдеры.

#21
11:03, 4 июля 2009

MarkoPolo
> Можешь смеяться, но мне что-то подсказывает, что если камеру помести вблизь
> поверхности, много треугольников не обрезать, а это различные РПГ от первого
> лица.

РПГ разные бывают... Невервинтер найтс не тоже самое что Фолаут 3...
Поэтому определить выигрышь оптимизации по жанру не получится...

#22
11:26, 4 июля 2009

Executor
Я Невервинтер бегал с action камерой... как ни странно. Потом у меня ассоциация rpg идет на морровинд... :( Постоянно забываю про то, что после прихода повсеместного 3D остались RPG в которых камеру вешают в изометрии. :(

#23
13:41, 4 июля 2009

MarkoPolo
> Я Невервинтер бегал с action камерой...

Dungeon Siege... Не суть...
Даже РТС бывает вид от первого лица...

> Постоянно забываю про то, что после прихода повсеместного 3D остались RPG в которых камеру вешают в изометрии. :(

Я понял, что ты имел ввиду, но слово изометрия тут не к месту...

#24
20:13, 4 июля 2009

Executor
Ладно, ладно, ты умный. Все действительно рисуется с перспективой.

#25
9:20, 21 сен. 2009

Кэш ощущается сразу. Ландшафт 1024x1024, но могу задавать размер блока(чтобы лод сделать потом). Так вот без полоски к кэшу:
10-27 ~ 230 fps
28-... ~130 fps

Вставляю в начало каждого блока фиктивную полосу для кэшинга:
10-54 ~ 230fps
55-... ~130fps

Вся геометрия выводится одним батчем.

8800GTS 512.

#26
10:54, 27 дек. 2009

т.е. для directX , чем меньше обращений к DrawPrimitives или DrawIndexedPrimitives тем лучше, или еще более : чем меньше обращений к Device - тем круче???? Или не всегда?

Блин в статье написано что батчей мало на мощном cpu - плохо, но слишком много тоже плохо и надо цпу грузить на 100%... Поясните, тру или не?

#27
20:32, 15 фев. 2010

Так как делаю ландшафт решил проверить...  прирост скорости на текстуре 256*256 ничего не дал  и тут решил самым надежным способом  все индексы вершин сделал равными 0 типа никуда из кеша не денется.
в итоге получил
1- 247 индексов 30fps
248 - 248*индексов - c 30 fps  падает  до 15 fps
248*2> 15-13fps так и держится  проверял с 532к индексами.


получается что  в кеше нет еще вершины с 0 индексом и она начинается вычисляться 247 раз в каждом шейдерном процессоре.
после окончания вычислений данные помещаются в кеш, но походу уже тест кеша прошла следующая партия вершин в итоге вершина с индексом 0 вычисляется повторно и падает fps с 30 до 15.

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

вот обрывок кода вершинного шейдера

  for(int i=0;i<2000000;i++)
  {
    color += vec4(0.0,0.0,0.0,0.00001);
  }

#28
23:07, 15 фев. 2010

fzr125
> чем меньше обращений к Device - тем круче???? Или не всегда?
тем короче у вас буфер команд. дорого стейты менять. Еще дороже точки синхронизации вида GetRenderTargetData

Страницы: 1 2
ПрограммированиеФорумГрафика

Тема в архиве.