Эффективность асинхронного выполнения AMD OpenCL

Question

Например, у меня есть три задачи A, B и C. Среди них B и C зависят от A. И есть достаточные CU для одновременного запуска B и C. И затем я вставляю A и C в очередь 0 и B в очередь1. И есть огромная задержка после завершения A и до начала B, что заставляет всю работу занимать больше времени, чем использовать только одну очередь.

Это нормально? Или я мог сделать что-то не так?

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

Answer 1

я не смог найти информацию о задержках, но назвать что-то нормальным, мы должны статистически полученными латентную базу для всех платформ, вот мой:

HD7870 и R7-240 показывает такое же поведение. Windows 10. Двухканальная ОЗУ. OpenCl 1.2 (64-битная сборка). Профилирование CodeXL. Все очереди в очереди. Некоторые старые водители перед малиновым.

• скучновата одна очередь с не-блокирующие команды: несколько микросекунд до 200 микросекунд колеблется, но в среднем должна быть низкой, как 50 микросекунд и в зависимости от драйверов, для некоторых ядер она идет до 500 микросекунд, может быть, из-за слишком большого числа параметров и аналогичные препараты.
• источник событий = одна очередь-А, целевое событие = очереди Б: 100-150 микросекунд до половины миллисекунды (казалось константа)
• источник событий = список N-1 очереди, целевое событие = queue- N: Не сумма всех задержек очередей, но скрытая скрытая видимость там, поэтому ее не более 2 миллисекунд (иногда пики до 3-5 миллисекунд редко)
• event source = queue, ожидания от clWaitForEvents от хоста : около миллисекунды
• источник события = очередь, ожидающий clGetEventI nfo от хоста в while-loop: почти половина миллисекунды, иногда даже меньше
• clFinish для одиночной очереди: Это имеет наибольшую задержку в очереди, как минимум, 1 мс.
• пользовательских событий: генерировали ошибки в кодексе, поэтому я не мог запросить их производительность, но это был более старый драйвер и более ранняя версия codeXL.

Были фоновые процессы: avira, google chrome, .., которые достаточно продвинуты, чтобы использовать GPU для своей цели и могут препятствовать выполнению ядра.

Мое решение для них заключалось в конвейерной обработке через использование многих независимых очередей, чтобы скрыть их задержки событий и работать как шарм. R7-240 работал на 16 очередях в порядке. Он имеет только 2 блока ACE, поэтому более новые карты, имеющие 4-8 из них, могут работать с большим количеством очередей.

Что я не пробовал и задаюсь вопросом: N очередь ждет завершения M других очередей с исполнением списка событий. Возможно, древовидная структура ожидания может быть лучше для многих очередей, если они слишком сильно отстают.