Я был включен в проект, который обрабатывает изображения на CPU и в настоящее время расширяется для использования GPU, а также , при этом предполагается, что в основном будет использоваться GPU, если это окажется быстрее, и обработать процессорную часть как запасной вариант.Я новичок в программировании на GPU и у меня есть несколько вопросов, аспекты которых я видел в других темах, но не смог найти ответы на свои вопросы.
Если мыначинали с нуля, какую технологию вы бы порекомендовали для обработки изображений на GPU, чтобы добиться оптимального сочетания покрытия (как при поддержке на клиентских машинах) и скорости?Мы пошли по пути OpenGL + GLSL , чтобы охватить как можно больше видеокарт, и мне любопытно, является ли это оптимальным выбором.Что бы вы сказали о OpenCL , например?
Учитывая, что мы уже начали реализацию модуля GPU с OpenGL и шейдерами, я хотел бы получить представление оделаем ли мы это наиболее эффективным способом.
Мы используем Framebuffer Objects для чтения и рендеринга в текстуры.В большинстве случаев читаемая область и записываемая область имеют одинаковый размер, но текстуры , из которых мы читаем и пишем, могут иметь произвольный размер .Другими словами, мы просим FBO прочитать подрайон того, что считается его входной текстурой, и записать в подрайон того, что считается его выходной текстурой.Для этого выходная текстура «присоединяется» к объекту Framebuffer (с помощью glFramebufferTexture2DEXT ()), а входная - нет.Это требует, чтобы текстуры были «прикреплены» и «отсоединены», так как они меняют свои роли (т. Е. Текстура может быть изначально использована для записи, но на следующем проходе она может использоваться как вход для чтения).
Вместо того, чтобы заставить входы и выходы иметь одинаковый размер и всегда иметь их присоединенные к FBO, имеет больше смысла , с точки зрения эффективного использования FBO и достижения лучшей производительности или делаетто, что у нас уже звучит достаточно хорошо?
Первоначально проект был спроектирован для рендеринга на процессоре, поэтому были приняты меры к тому, чтобы запросы обрабатывались как можно меньше пикселей за раз,Таким образом, всякий раз, когда происходит перемещение мыши, например, только очень маленькая область вокруг курсора будет перерисована.Или при рендеринге всего изображения, которое покрывает экран, оно может быть нарезано на полосы для визуализации и отображения один за другим. Имеет ли смысл такая фрагментация при рендеринге на графическом процессоре? Каков наилучший способ определения оптимального размера для запроса рендеринга (т. Е. Выходной текстуры), чтобы графический процессор использовался полностью?
Какие соображения будут при профилировании кода (для производительности), который выполняется на GPU ?(Чтобы сравнить это с рендерингом на процессоре.) Является ли измерение полезного времени, которое требуется для возврата (и вызов glFinish (), чтобы убедиться, что команды выполнены на GPU), полезно или есть что-то еще, о чем стоит помнить?
Большое спасибо!
Я думаю, мне нужно добавить пару деталей, чтобы уточнить мои вопросы:
2) На самом деле мы не используем одну и ту же текстуру в качестве цели рендеринга и источника чтения одновременно.Только когда рендеринг закончен, «выходная» текстура становится «входной», т. Е. Когда результат задания рендеринга необходимо прочитать для другого прохода или как вход для другого фильтра.
Что меня беспокоилос тем, будут ли прикрепленные текстуры обрабатываться по-разному, например, будет ли FBO или шейдер иметь более быстрый доступ к ним по сравнению с тем, когда они не присоединены.
Мое первоначальное (хотя, возможно, и не совсем точное) профилирование не показало существенных различий, поэтому я полагаю, что мы не совершаем такого большого количества преступления производительности. Я сделаю больше тестов с предложенными вами функциями синхронизации - они выглядят полезными.
3) Мне было интересно, будет ли медленнее или быстрее разделить картинку на мелкие кусочки (скажем, размером 100 x 100 пикселей для перемещения мыши) и запросить их рендеринг по одному. или это не имеет значения) на GPU, который потенциально может парализовать большую часть работы. У меня есть ощущение, что это может быть чрезмерно оптимистичной оптимизацией, которая в лучшем случае не принесет нам большой пользы, а в худшем может повредить производительности, поэтому я задавался вопросом, существует ли формальный способ определения конкретной реализации. В конце концов, я полагаю, что мы будем использовать то, что кажется разумным для разных видеокарт.