Имеет ли смысл кэшировать функции trigonometri c в OpenGL ES?

Question

Я знаю, что кеши тригонометрических функций были очень популярны при работе с графикой до графических процессоров, но имеет ли смысл использовать таблицу поиска текстур 1D для вычисления sin / cos из предварительно вычисленного значения из шейдера OpenGL ES? Есть ли экономия времени, если сверхвысокая точность не требуется?

Answer 1

Да, это имеет смысл, и вы должны его кешировать.

Сначала я прочитал ответ solidpixel (он в основном правильный), но я немного отклонюсь от него.

Итак, в Короче говоря: вы не должны вычислять sin () и cos () во время выполнения (особенно в android - если это ваш случай GLES), потому что вы не знаете, на каком графическом процессоре будет работать ваш шейдер, и многие из них просто будут никогда не оптимизируйте это. Есть и другие способы кеширования, кроме использования выборки текстур.

Если вы имеете дело с линейной алгеброй (большинство процедур шейдеров - это простые решатели векторных уравнений), тогда: вы должны использовать точечный продукт, чтобы заменить необходимость в cos() и кросс-продукт для sin(), как он сказал.

Однако, если это не ваш случай, и вам действительно нужно вызвать sin и cos, то я рекомендую вам кешировать это наверняка, вот 2 лучших способа Мне нравится:

• texture() действительно довольно дорого, но вы можете использовать textureGrad(), что является довольно быстрым поиском текстур, чем обычный texture(), потому что он пропускает всю фильтрацию, хотя и более ограничен, он идеально подходит для кэширования sin и cos.
• Другое лучшее решение - вообще не использовать текстуру: вместо этого используйте однородные буферы, в основном это будет массив с плавающей точкой (например, текстура), но явный для GPU, поэтому вам не нужно проходить выборку (что особенно дорого для мобильных устройств).
• одинаковые буферы имеют ограничение по размеру поэтому, если вам нужна лучшая точность при различных значениях угла, вы можете использовать SSBO (объекты хранилища буфера шейдеров), которые похожи на единообразные буферы, но могут хранить гораздо больше данных.

Answer 2

Это один из тех вопросов "это зависит".

Высокоточные произвольные sin() и cos(), в частности, как правило, являются дорогостоящими операциями, поскольку они не часто используются непосредственно в графике, а получение полной точности, как правило, требует некоторого уровня итерации уточнения. Поэтому по отдельности меня не удивит, если текстурирование будет быстрее.

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

Во-вторых, стоит отметить, что некоторые реализации (в частности, мобильные графические процессоры), вероятно, уже смогут дать вам более быстрые и менее точные результаты, если вы будете вычислять с точностью mediump. Это уменьшит базовую стоимость для sin() или cos() в логи c ниже.

Остальная часть вопроса на самом деле заключается в том, лучше ли стоимость sin(), чем стоимость texture(), который, вероятно, очень сильно зависит от остальной части программы шейдера и баланса функциональных блоков в целевом графическом процессоре.

• Если в вашем шейдере уже преобладает производительность текстурирования из-за других не связанных Операции с текстурой, а затем добавление большего количества текстур сделает его медленнее, даже если отдельный вызов texture() индивидуально быстрее, чем sin().
• Если в вашем шейдере преобладает арифметика c (или любые другие единицы) выполняет sin() вызовов), тогда производительность может улучшиться, перенеся некоторую нагрузку с этого на путь текстурирования.