Как ускорить рендеринг за пределами экрана OpenGL с большими текстурами на Win32?

Question

Я разрабатываю некоторый код на C ++, который может создавать причудливые эффекты 3D-перехода между двумя изображениями, для которых я думал, что OpenGL будет лучшим вариантом.

Я начинаю с раздела DIB и настраиваю его для OpenGL, и создаю две текстуры из входных изображений.

Затем для каждого кадра я рисую только два квадда OpenGL с соответствующей текстурой изображения. Содержимое DIB затем сохраняется в файл.

Например, один из эффектов - найти два квадрацикла (в трехмерном пространстве), как два билборда, один перед другим (скрывая его), а затем повернуть камеру вверх, вперед и вниз, чтобы вы могли видеть второй .

Мои входные изображения имеют разрешение 1024x768 или около того, и рендеринг занимает очень много времени (100 миллисекунд), когда квадраторы покрывают большую часть изображения. Ускоряется, если камера находится далеко.

Я пытался визуализировать каждое изображение квадратов как сотни отдельных плиток, но это занимает столько же времени, похоже, это зависит от количества видимых текстурированных пикселей.

Я предполагал, что OpenGL может делать миллионы полигонов в секунду. Я что-то упускаю здесь?

Будет ли мне лучше использовать какой-то другой подход?

Заранее спасибо ...

Редактировать:

Строки GL отображаются для версии DIB как:

Поставщик: Microsoft Corporation Версия: 1.1.0 Renderer: GDI Generic

Экранная версия показывает: Поставщик: ATI Technologies Inc. Версия: 3.2.9756 Контекст профиля совместимости Рендерер: ATI Mobility Radeon HD 3400 Series

Так что, я думаю, мне придется использовать FBO, я немного запутался в том, как вывести визуализированные данные из FBO на DIB, какие-нибудь указатели (каламбур) на это?

Answer 1

Похоже, что рендеринг в DIB заставляет рендеринг происходить в программном обеспечении. Я рендерил бы объект буфера кадра, а затем извлекал данные из сгенерированной текстуры. Gamedev.net имеет довольно приличный учебник .

Имейте в виду, однако, что графическое оборудование ориентировано в первую очередь на рисование на экране. Захват визуализированных данных, как правило, будет медленнее, чем их отображение, даже если вы получаете аппаратное обеспечение для рендеринга, хотя оно все равно должно быть немного быстрее программного рендеринга.

Редактировать: Dominik Göddeke имеет учебник , который включает код для считывания данных текстуры в адресное пространство процессора.

Answer 2

Одна проблема с вашим вопросом:
Вы не указали реальный код рендеринга / генерации текстуры.

Не лучше ли использовать другой подход?

Самое простое, что вы можете сделать, это убедиться, что ваши текстуры имеют размеры, равные степени двойки.Т.е. вместо 1024x768 используйте 1024x1024 и используйте только часть этой текстуры.Объяснение: хотя большинство современного оборудования поддерживает текстуры не-pow2, они иногда рассматриваются как «особый случай», и использование такой текстуры МОЖЕТ привести к падению производительности на некоторых аппаратных средствах.

Я предположил, что OpenGL может сделать миллионыиз полигонов в секунду.Я что-то упускаю здесь?

Да, вы упускаете одну важную вещь.Есть несколько вещей, которые ограничивают производительность графического процессора:
1. Скорость передачи системной памяти в видеопамять (вероятно, не в вашем случае - только для динамических текстур \ геометрии, когда данные меняются в каждом кадре).
2. Стоимость вычислений.(Если вы пишете шейдер с большими вычислениями, он будет медленным).
3. Скорость заполнения (сколько пикселей программа может выводить на экран в секунду), AFAIK зависит от скорости памяти на современных графических процессорах.
4.Скорость обработки вершин (не ваш случай) - сколько вершин GPU может обрабатывать в секунду.
5. Скорость чтения текстур (сколько текселей в секунду может считывать GPU), в современных GPU зависит от скорости памяти GPU.
6Кэширование чтения текстур (не ваш случай) - то есть в фрагментном шейдере вы можете прочитать текстуру несколько сотен раз на пиксель с небольшим падением производительности, если координаты очень близки друг к другу (то есть почти одинаковые тексели в каждом чтении) - потому что результаты кэшируются.Но производительность значительно снизится, если вы попытаетесь получить доступ к 100 случайно расположенным текселям для каждого пикселя.

Все эти характеристики зависят от аппаратного обеспечения.

То есть, в зависимости от некоторого оборудования, вы можете отрендерить 1500000 полигонов на кадр (если они занимают небольшое место на экране), но вы можете довести fps до колен с помощью 100 полигонов, если каждый полигон заполняет весь экран., использует альфа-смешивание и текстурированную с высокой степенью детализации текстуры.

Если вы подумаете об этом, вы можете заметить, что есть много видеокарт, которые могут рисовать пейзаж, но fps падает, когда выделать эффекты кадрового буфера (такие как размытие, HDR и т. д.).

Кроме того, вы можете получить снижение производительности на текстурированных поверхностях, если у вас есть встроенный графический процессор.Когда я готовил слот PCIEE на предыдущей материнской плате, мне приходилось работать со встроенным графическим процессором (NVidia 6800 или что-то еще).Результаты не были приятными.Хотя GPU поддерживает модель шейдеров 3.0 и может использовать относительно дорогие в вычислительном отношении шейдеры, частота кадров быстро падает каждый раз, когда на экране появляется текстурированный объект.Очевидно, это произошло потому, что встроенный графический процессор использовал часть системной памяти в качестве видеопамяти, а скорости передачи в «обычной» памяти графического процессора и системной памяти различаются.