Кстати, если тут кого-то эта проблема с ДХ12 драйверами АМД на старых ЦП действительно затрагивает, я бы порекомендовал попробовать пообщаться с их техподдержкой, я видел по крайней мере несколько случаев, когда от этого был толк. До сих пор склоняюсь к тому, что эта проблема - просто чья-то халатность

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

А когда без костыля будет в вольте?

загадка, может вообще никогда

Смотря что считать костылём. Async - тоже костыль, потому что AMD не в состоянии нормально загрузить видяху работой.

Какой еще костыль? Async дает буст потому, что в определенное время вычислительные ресурсы без него не используются, а с ним используются. Preemption - это не костыль, а механизм, запускающий что-то на выполнение заранее, неотъемлемое условие заметного ускорения от использования асинхронных вычислений. От того, как хорошо сделан preemption, зависит скорость переключения с одной задачи на другую. AMD им активно пользуется. Maxwell не поддерживает его аппаратно, он умеет только в сам async, т.е. запустить графику и несколько compute-задач на нем можно в параллель. При этом до запуска каждой следующей порции придется ждать выполнения самой долгой операции. Переключение с одной задачи на другую влечет заметные накладные расходы и не может происходить слишком часто, Maxwell должен завершить последний draw call до конца.. В итоге без хорошего планирования и предсказания в драйвере он скорее потеряет в скорости, т.к. вынужденный простой блоков увеличится. Действительно получатся выгоднее выполнить последовательно. Но у nvidia никогда и не было особых проблем загрузить GPU работой. Потому то их GPU и не отстают от аналогов AMD с более высоким числом gflops.
Pascal умеет сам на лету перераспределять ресурсы, отдавая освободившееся еще не закончившемуся процессу (maxwell продолжает считать зависший процесс только на том, что ему изначально было выделено планировщиком при запуске), заодно научился нормальному preemption - переключение доступно вплоть до уровня отдельных инструкций с заявленной задержкой не более 1/10000с.

Ugh, этот аргумент используется снова и снова, снова и снова. Но критики он не выдерживает. НВ удаётся все блоки карты на 100% держать загруженными? Конечно же нет, пускай у них эффективность и выше
И такой сценарий использования async compute лишь 1 из возможных, они могут быть не только низкого приоритета( заполнять работой свободные блоки карты ), но и высокого, и могут быть использованы для выполнения какой-то срочной работы, например, если CPU нужно получить её результат от GPU. При использовании синхронных очередей, CPU придётся ждать, в типичном случае, гораздо дольше, прежде чем результат станет доступен

На 100% никто не может, даже Intel с HT и Sparc с 8 потоками на ядро.
Как и Async не может, о чём AMD прямо и заявляет в своих слайдах, потому что борьба за ресурсы и боттлнеки во все поля.

Другое дело, что без асинка у AMD фиговые шедулеры (как аппаратный, так и софтовый), которые сливают в рантайме хуанговским.
Вот и переложили с больной головы на здоровую - пусть разработчики игр сами долбаются с тем, чтоб видяхи работой загрузить.



Если говорить о приоритетах, то тогда ни одна видеокарта до GCN1.2 не умеет в нормальный асинк, ибо у них там QoS не пашет. О чём AMD тоже сама заявляла в контексте Kaveri vs Carrizo

100% недостижимы даже с async. Для AMD позор состоит в том, что старый maxwell без асинка загружен лучше, чем полярис с ним. На примере того же AoS смотрим теоретические спеки чипов и фактический fps.

То есть раньше на них это не перекладывали? Это в каком-то ДХ11, в котором нужно было читать бесчисленные мануалы по оптимизации, чтобы не спровоцировать кучу боттлнеков? На любых картах

Речь не шла о 100% загрузке с асинк, сразу 2 человека неправильно интерпретировали мои слова. Речь была про то, что видеокарты сильно недозагружены как у НВ, так и у АМД. Асинк не будет магическим решением, которое сделает любую игру с ним страшнее Furmark, но с проблемой может существенно помочь
И это всё ортогонально идёт с моим поинтом, который в том, что от async compute с низким приоритетом могут получить прирост все, и это отличное добавление в API. Ранние провалы НВ в поддержке никак это не отменяют

Часто переключать контекст туда-обратно - тоже не самая светлая идея, особенно на GPU. По слайду nvidia паскалю нужно менее 1/10000с на переключение. Это очень мало для GPU, но примерно в 100 раз хуже любого CPU (которые архитектурно лучше к этому приспособлены). Для GPU AMD цифр не нашел, но скорее всего где-то рядом с паскалем (или даже хуже из-за более низкой тактовой частоты).

У сандаля что-то в районе 1500ns на переключение, если не инвалидировать кэши.
У core2 пишут про 6000ns

Асинхронные шейдеры с низким приоритетом должны использовать бесплатный context switch, с высоким приоритетом - preemption switch, который дорогой( 100 микросекунд - огромное количество времени, GPU или нет ). Асинхронные задачи с высоким приоритетом в другой категории, нежели с низким, если кто-то решил использовать их, а они будут исполнены как синхронные, скорее всего, результатом будет неприемлемая задержка. Тут реально может потребоваться фоллбек, в отличие от асинхронных с низким приоритетом, где отсутствие поддержки едва ли даст негативные эффекты помимо некоторого падения производительности( вместо увеличения )
Я кстати не уверен, что с высоким приоритетом всегда _обязаны_ использовать дорогой preemption, если её видеокарта поддерживает, возможно, тут есть варианты. Как-нибудь поищу информацию про это

Добавлено спустя 16 минут 48 секунд:

Ну, очевидно, это решает производитель видеокарты. ДХ12 даёт только задать высокий приоритет и не даёт никаких гарантий. В некоторых случаях этот приоритет полностью игнорируется, задача выполняется как синхронная, что убивает вообще весь потенциал использования. При таком раскладе, вряд ли этот тип асинк компьют скоро в играх получит распространение

Откуда взялось бесплатное переключение контекста? Каждый перескок - это простой SM/CU, хотя цифр особо никто не афиширует. Подозреваю, что высокоприоритетный preemption дороже, т.к. требует куда-то сбросить состояние прерванного потока, сохранить кеши, а потом все восстановить. Опять же нет никакой гарантии, что разработчик софта может или будет заморачиваться с загрузкой ресурсов больше/лучше разработчиков драйвера.

Это правильно. Если приоритет не важен, то лучше, чтобы очередь выполнения определял драйвер.

Вот тут, например, явно заявлено: "context switching is free – every cycle"

Программист указывает максимальный приоритет( на выбор только 2, нормальный и высокий ), драйвер это просто игнорит и делает как захочет, выбирая долгий путь выполнения, в итоге ничего не работает так, как задумано. Я бы сказал, что это явно неправильно, но так сейчас может получаться

Ну что ж, им придётся постараться, чтобы получить производительность. Ничего принципиально не меняется в сравнении с DX11. На консолях всегда были низкоуровневые API и это преподносилось как возможность выжать из железа больше. Я не программировал для консолей, но разработчики с опытом кроссплатформенной разработки говорили, что на консолях API существенно ниже уровнем и ближе к железу, чем 12. DX12 низкоуровневый в сравнении с 11. Почему-то после его появления на ПК, при том, что он не сделал устаревшим 11, а просто был добавлен как альтернатива, появилось куча аргументов про то, что это не работа разработчиков. Хотя они её до этого десятками лет делали на консолях и сами просили о большем контроле на ПК

Xbox использует DirectX, на данный момент 12, на старте 11.2. Никакого специального API там нет. По сути там та же самая винда с измененным GUI.

На PS4 2 графических API. GNM и высокоуровневая обертка вокруг него (GNMX). Все разработчики, что в здравом уме и не делают экз по заказу, пишут через обертку. Разработчик по природе ленив и делая мультиплатформу меньше всего заинтересован к копании внутренностей каждой отдельной железки. Проще просто порезать картинку.

Нет и нет, не 11.2 и 12, а 11.Х и 12.Х

Вот тут разработчик DOOM говорит о том, что DX12 на XBO и Windows очень разные. На XBO потребуется отдельный код при желании добиться оптимальной производительности

Я бы обошёлся без таких обобщений. Кто хотел выжать максимум, использовал низкоуровневые API

Да и да. Нет в SDK никаких X.

А это и есть обобщение. У разработчика мультиплатформы "выжать максимум" имеет довольно низкий приоритет в большом списке дел.

Что весьма логично из-за особенностей памяти и процессора в коробке.

Где-то может и нет, где-то есть
Было бы логично иметь разные названия, учитывая, что десктопные и консольные версии API имеют большие различия


Чем это вообще подкреплено, может, у вас есть цифры, которые показывают, насколько широко были использованы доступные низкоуровневые API, и насколько часто выбирались сторонние или нативные обёртки над ними? Мне было бы интересно на них взглянуть
Это не то чтобы графика не была болшим selling point, особенно, когда нужно её постоянно совершенствовать, работая на всё том же, устаревающем железе