2013-09-14 2 views
7

Я слышал, что получение текстуры - довольно дорогая операция. Но сколько? как десятикратное арифметическое умножение.Насколько дорогой выбор текстуры в GLSL?

Например, есть 3D-просмотровой метод таблицы для обработки изображения, которая требует выборку 3d текстур один раз:

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter24.html

Даже если преобразование может быть достигнуто только с некоторой матрицей и векторным произведением в шейдере, могу ли я ожидать, что 3D-LUT по-прежнему будет полезен с точки зрения производительности?

3D-LUT против матричного/векторного продукта - всего лишь пример. То, что я хочу знать, это общий способ оценки накладных расходов путем извлечения текстуры перед измерением точного времени работы. Или есть что-то вроде «чит-листа» для накладных расходов GLSL?

+1

Это зависит от поставщика, на карту, для каждой ОС. Вы не получите ни одного хорошего ответа. Если у вас есть специальное оборудование, с которым вы работаете, вы должны его профайл. Есть ли причина думать, что выборки текстур являются узким местом для вашего приложения? По моему опыту, накладные расходы на настройку текстур, подлежащих обработке, затмевают накладные расходы шейдеров. – user1118321

+2

Я скажу так много сейчас - GPU Gems 2 - очень старая книга. Когда это было написано, нормализация cubemaps все еще была законной вещью на некоторых аппаратных средствах (да, выборка из карты куба была быстрее, чем нормализация векторов, использующих арифметику, а затем на некоторых аппаратных средствах). В наши дни инструкции на _lot_ дешевле, чем выборки памяти, то же самое верно в мире процессоров - никто не использует таблицы поиска для триггера. функций на современных процессорах. В любом случае, это действительно зависит от вашего прецедента, если вы можете заменить достаточное количество инструкций с помощью одного поиска, вы можете выиграть. –

+0

@ user1118321 Я не нацелен на конкретное оборудование. Точнее, моя цель - все устройства основного поставщика, поддерживающие OpenGL 2.0 или выше. Как я уже сказал, то, что я действительно хочу знать, является общим методом оценки накладных расходов из кода GLSL. Если нет общего ответа, как вы сказали, это означает, что это обычная вещь для тестирования в определенном аппаратном обеспечении, и я должен проверить каждую комбинацию оборудования/драйвера, которая не является реалистичной. – xylosper

ответ

7

От этого зависит всегда. Одной из проблем с выборками текстур является пропускная способность памяти и - весьма связанная с этим - эффективность кеша. Кэширование оптимизировано для случая, когда соседние фрагменты получают доступ к соседним текселям. Я сделал некоторые тесты, и в таком сценарии я даже не заметил никакой разницы между выборкой с ближайшей или выборкой с билинейным фильтром и напрямую с использованием texelFetch.

В другом сценарии, когда я использовал 3D-текстуру в качестве цветового поиска, эффективность кеша стала серьезной проблемой. Качество изображения существенно влияет на производительность. Мой тестовый сценарий состоял в постобработке кадра 1920x1080 и с довольно удобным для кеша контентом (снимок экрана офиса ms), я измерил около 0,35 м для операции, а с изображением, содержащим случайный шум, время обработки увеличилось до ~ 4 мс (с билинейной фильтрацией) или ~ 2 мс (ближайший/texelFetch).

Конечно, это зависит от вашего конкретного сценария и аппаратного обеспечения, поэтому единственным советом, который я могу дать, является: benchmark/profile it.

+0

На самом деле, я уже тестировал свои коды, и я не мог найти разницы. Поэтому я думаю, что пропускная способность памяти не является узким местом в моем GPU. Но, как вы сказали, конкретный результат зависит от устройства и водителя. Вот почему я хочу знать «общий способ оценки», даже если он не является точным. В любом случае, теперь я вижу, что кеш-промах - большая проблема для получения текстуры из вашего ответа. Спасибо. – xylosper

+0

@xylosper: действительно большая вещь, которую вы должны учитывать при работе с извлечением памяти в графических процессорах, заключается в том, что их память значительно выше, чем у процессоров; они торгуют латентностью для полосы пропускания. Обычно графические процессоры скрывают этот факт, планируя запуск других шейдеров во время загрузки памяти, и это очень хорошо работает для высокопараллельных задач данных, таких как вершинное затенение, но когда вы начинаете получать данные текстур из случайных/зависимых мест, он действительно может начать раскрывать базовая латентность. Итак, как вы говорите, кеш - это важно, даже более важно, чем в процессорах. –

+0

Использование ближайшего к билинейному не должно сильно влиять на скорость, поскольку современное оборудование выбирает 4 текселя независимо от того, что происходит (если это не сделано на аппаратном уровне), практически бесплатно. – imallett

Смежные вопросы