Плохая производительность OpenGL с 3D-текстурой

Я пытаюсь реализовать Volume Renderer с OpenGL и raycasting. Все работает хорошо, но у меня возникают проблемы с производительностью, когда я смотрю в отрицательном направлении. Это означает, что если я смотрю в положительном направлении x (просматривая вектор 1, 0, 0), производительность в порядке. Но если я смотрю в отрицательном направлении x (-1, 0, 0), частота кадров снижается до 2-3 кадров в секунду. Я использую 3D-текстуру для хранения данных набора данных im. Может проблема с кешированием текстуры на GPU? Или в чем может быть проблема, что частота кадров снижается, когда я смотрю в отрицательном направлении?

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


glsl opengl volume-rendering
person user1844213    schedule 29.05.2013    source источник
comment
Возможно, это проблема с трассировкой лучей через трехмерный объем. Я не вижу причин ожидать, что это будет быстро, когда вы потенциально делаете десятки обращений к текстуре для каждого фрагмента.   -  person Nicol Bolas    schedule 29.05.2013
comment
Я знаю, что у меня много обращений к текстурам для каждого фрагмента, и я реализовал кое-что для оптимизации. Мой raycast работает быстро, когда луч имеет положительное направление. Таким образом, GPU может обрабатывать такое количество обращений к памяти.   -  person user1844213    schedule 29.05.2013
comment
Я установил Mig and Mag Filter на GL_NEAREST, и производительность стала немного лучше, но не идеальной. Станет ли изменение 3D-текстуры на объект буфера текстуры более производительным?   -  person user1844213    schedule 29.05.2013

Ответы (1)


arrow_upward
1
arrow_downward

В этой ситуации нужно учитывать две вещи:

  • шаблон доступа к памяти

а также

  • подкачка текстурных данных

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

Трехмерные текстуры потребляют очень много памяти. OpenGL использует абстрактную модель памяти, в которой нет явных ограничений на размер таких объектов, как текстуры. Либо их загрузка работает, либо нет. И если драйвер может управлять этим, вы можете загружать текстуры большего размера, чем умещается в памяти графического процессора. По сути, память графического процессора является кэшем для данных OpenGL. И если ваша 3D-текстура окажется больше, чем доступная память графического процессора, это может быть связано с тем, что реализация OpenGL подменяет данные текстуры во время доступа к ней при рендеринге. Если ваш шаблон доступа удачный, этот процесс подкачки хорошо вписывается «в промежутки» и может как бы передавать данные текстуры в кеш (под которым я имею в виду память графического процессора) прямо перед тем, как это потребуется, без остановки процесса рендеринга. Однако другой шаблон доступа (другое представление) не будет хорошо работать с заменой данных по запросу, что приведет к снижению производительности.

Я предлагаю вам уменьшить размер вашей 3D-текстуры.

person datenwolf    schedule 29.05.2013
comment
Я думаю, что подкачка текстурных данных не проблема. Я проанализировал память графического процессора во время рендеринга и после загрузки текстуры свободной памяти достаточно. Я думаю, что шаблон доступа к памяти может быть правильным. Могу ли я изменить или повлиять на шаблон доступа к памяти с помощью OpenGL? Я ничего не могу найти об этом. - person user1844213; 29.05.2013
comment
@ user1844213: Вы ничего не можете с этим поделать. Порядок, в котором фрагменты в фреймбуфере обрабатываются, либо жестко запрограммирован, либо жестко связан с комбинацией графического процессора и драйвера, и в raycaster есть немного больше, чем выбор направления обработки луча. Некоторые стили прямого объемного рендеринга могут обрабатываться спереди назад и заканчиваться раньше (для каждого луча), в то время как другие работают только сзади вперед и должны обрабатывать весь диапазон внутри объема. Вы могли бы получить более быстрый графический процессор ;) Также большое влияние может иметь субдискретизация лучей; это единственная ручка, которую я поворачиваю, когда сталкиваюсь с проблемами производительности. - person datenwolf; 29.05.2013