Сколько прямых / вычислительных / копий очередей имеют смысл?


11

DirectX 12 предоставляет очереди команд для графических задач (называемых «Direct»), для вычислений или копирования. С точки зрения предоставленной функциональности каждый из них является супер-набором следующего. Спецификация утверждает , что очереди команд могут быть выполнены одновременно с помощью устройства. Тем не менее, API никоим образом не ограничивает количество очередей команд (по крайней мере, я не знаю каких-либо ограничений).

По-видимому, разные поставщики обрабатывают это очень по-разному:

  • В недавней презентации Intel (слайд 23) говорится, что в настоящее время их графические процессоры не способны параллельно обрабатывать графику и вычисления и что у механизма копирования низкая пропускная способность. Они не рекомендуют использовать несколько графических / вычислительных очередей.
  • AMD давно начала рекламировать использование очередей / «асинхронных шейдеров», начиная с Mantle и консолей текущего поколения. Есть также некоторые разработчики ( пример ), которые подтверждают значительный выигрыш в производительности, выполняя параллельные вычислительные и графические задачи.
  • В последнее время возникла некоторая суета по поводу того, что Nvidia не поддерживает асинхронный шейдер в аппаратном обеспечении: одновременное использование отдельной очереди графики и вычислений замедляет работу, что указывает на эмуляцию драйвера. С другой стороны, операции параллельного копирования поддерживаются CUDA в течение очень долгого времени, что дает понять, что механизм DMA может работать независимо.

Есть ли способ решить во время выполнения, имеет ли смысл фиксировать CommandLists для нескольких CommandQueues вместо одного? (учитывая, что предыдущий случай не требует больших технических затрат)

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


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

1
хороший вопрос ! я также чувствую, что было бы особенным получить одновременное выполнение вычислений и теней. возможно, выигрыш может произойти благодаря тем же фактам, которые ускоряют гиперпоточность. чередование операций, когда некоторые устройства заняты для другой очереди. как шейдеры, забивающие текстурные блоки, которые не используются на этапе вычислений, который сам забивает FPU или DPU.
v.oddou

Хм тоже плохо. Может быть, тогда, «кроме проверки, кто делает GPU, нет», уже считается ответом, если не более того. После прочтения всех этих маркетинговых материалов AMD я рад слышать, что я не одинок в своем замешательстве.
Wumpf

1
Вы знаете, просто чтобы поднять немного веса в важность (на самом деле неважность) этого вопроса. В PS4 SDK есть ошибка, из-за которой невозможна передача в любую другую очередь, кроме очереди 0. Я думаю, что если бы это было так важно, это было бы исправлено быстрее.
v.oddou

Ответы:


1

Отправьте ваше приложение с последовательностью тестирования, проверяющей реальную платформу. (Возможный ответ на многие вопросы, я думаю ...)

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

«... очереди команд могут выполняться одновременно устройством ...»

Ключевое слово МОЖЕТ. Я не вижу причин, по которым какой-либо поставщик мог бы это испортить. В конце концов, именно провайдер платформы (Intel / AMD / Nvidia) отвечает за то, чтобы сделать вас достаточно хорошим драйвером, чтобы вы не рассматривали вопрос о смене поставщика. Если у них есть «известная проблема» с этой функциональностью (которая, кстати, не имеет никакого функционального значения, только производительность), то они должны также решить ее, используя то, что они знают. Я имею в виду, что они громко кричат, отступление - это то, что они уже реализовали; Синхронное исполнение.

Аппаратное обеспечение достаточно вуду, как и для нас, разработчиков.


AMD GCN будет выполнять графику и вычислять одновременно, даже если они оба выданы в графической очереди, но, как правило, не в нескольких буферах команд (несколько вызовов отрисовки могут быть даже отрывочными). Драйвер (или приложение - я думаю, в DX12 или Vulkan) должен проверять зависимости данных и блокировать между рисованием (графикой) и диспетчеризацией (вычислением) при необходимости. Несколько командных очередей, вероятно, были бы полезны, если у вас есть вычисления, которые действительно асинхронны из графики (например, физика для следующего кадра), но у меня нет прямого опыта с этим.
Даниэль М Гессель
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.