Каков самый быстрый кроссплатформенный способ извлечения определенных вершин в процессор?

Question

Я работаю над приложением, в котором я передаю позу камеры графическому процессору, который будет генерировать текстуры, содержащие различную информацию о видимых углах объекта (глубина нормали ...) На основе этой информации я хочу выбрать нескольковершины и просмотрите сгенерированные текстуры, чтобы получить всю информацию об этих вершинах в ЦП.

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

Answer 1

Преобразование обратной связи * Механизм 1002 * не является вашим решением. Это хорошо для захвата текущего состояния данных на графическом процессоре и обновления его для следующего вызова отрисовки на графическом процессоре без необходимости выполнять преобразование графического процессора в центральный процессор и обратный пинг-понг для обновления данных. Рендеринг частиц - один из популярных вариантов использования обратной связи преобразования. Вы не сказали, какая у вас целевая платформа, поэтому трудно понять ваши аппаратные ограничения / возможности, но вот несколько способов загрузить обновления хоста (ЦП) без остановки конвейера рендеринга:

1. Использование PBO-ping-pong . Если вы можете записать свои данные в текстуру, вы можете загрузить, а также выгрузить из / в GPU асинхронно , используя пиксельные буферные объекты. если вы прочтете документ по ссылке, вы также увидите, что вы можете продвинуть его еще дальше с помощью многопоточной передачи с использованием общего контекста. Эти методы значительно ускоряют время передачи.

2. Если вы работаете с буферами и имеете доступ к функциям постоянного отображения (OpenGL 4.4), вы можете попробовать двойную и даже тройную буферизацию, которая является своего рода «пинг-понгом PBO», как описано выше, но с использованием буферов , Здесь эта концепция подробно объясняется, но общая идея состоит в том, чтобы постоянно отображать буфер в 3 раза используемого размера, и каждый кадр считывать из одной из трех частей на хосте, а записывать в другую из трех части на устройстве. Закрепленный блок памяти виден для графического процессора, , вероятно, , через DMA, и, хотя в общем случае постоянные отображаемые буферы работают не быстрее, чем обычные, они значительно снижают издержки драйвера при каждом обновлении кадра.

3. Тяжелое каноническое использование CUDA или OpenCL в отдельном потоке. Я не знаю, как это сделать с OpenCL, но с CUDA вы можете установить контекст CUDA в отдельном потоке, сопоставить ресурс GL , например, буфер или текстуру, с ресурсами, принадлежащими CUDA, а затем с помощью данных чтения производителя - потребительской парадигмы для размещения из буфера GL, отображенного в CUDA, при этом продолжайте рендеринг в потоке OpenGL. Конечно, вам придется синхронизировать потоки, так как OpenGL не должен получать доступ к буферу , пока он отображается в контексте CUDA, так как результаты такого доступа будут неопределенными.

Лично я бы выбрал вариант 2 + использовать общий контекст и поток для постоянно отображаемого указателя для считываемых данных. У него есть свои сложности с синхронизацией, но если все сделано правильно, это может дать вам очень быстрое решение.