Войти
ПрограммированиеФорумГрафика

Directx 12 вопросы. (30 стр)

Страницы: 127 28 29 30 31 32 Следующая »
#435
9:13, 27 июня 2021

prowkan
> Странно, у меня наоборот RenderDoc нормально работает с моими (и чужими)
> поделками.

на UE4 у меня также


#436
20:40, 4 сен. 2021

Интересное наблюдение:
на Intel 620 поддерживается async compute и внезапно, дает прирост производительности побольше чем RTX 2080 с кучей хардварных модулей для async compute.
А на вулкане у интела только одна графическая очередь доступна, то есть в майкрософте смогли написать драйвера намного лучше, чем сами интеловцы в вулкане, хотя драйвера для вулкана сделаны достаточно хорошо.

#437
22:40, 4 сен. 2021

/A\
> на Intel 620 поддерживается async compute и внезапно, дает прирост производительности побольше чем RTX 2080 с кучей хардварных модулей для async compute.
Скорее всего потому что растеризаторы на 2080 вывозят, а на 620 - нет.
> А на вулкане у интела только одна графическая очередь доступна, то есть в майкрософте смогли написать драйвера намного лучше, чем сами интеловцы в вулкане, хотя драйвера для вулкана сделаны достаточно хорошо.
Очереди в вулкане - это аппаратные GPU-очереди, очереди в DirectX 12 - это программные прослойки, которые потом пушатся в настоящие очереди.

#438
10:40, 5 сен. 2021

phridrich
> очереди в DirectX 12 - это программные прослойки, которые потом пушатся в настоящие очереди.
Но как настоящие очереди могут выполнять рендеринг и компьют параллельно?

#439
11:50, 5 сен. 2021

/A\
А, в смысле там одна 3D очередь, а Compute - нету? Тогда не знаю.

#440
(Правка: 2:39) 2:32, 6 сен. 2021

/A\
> как настоящие очереди могут выполнять рендеринг и компьют параллельно?
В DX12 три очереди, одна для комьюта вторая для графики и третья для копирования. Они все по идее могут выполняться одновременно. Как на самом деле идет перераспределение ресурсов знают только разработчики драйвера. Это програмно контролировать нельзя. Если судить по диаграммам то выполнение действительно идет в параллель, но общая скорость падает ибо чудес нет. Но это падение меньше чем было бы при последовательном выполнении, т.е. три очереди работают быстрее чем одна.

#441
(Правка: 3:02) 2:50, 6 сен. 2021

phridrich
> Очереди в вулкане - это аппаратные GPU-очереди
Чтоб такое обслужить там должны быть отдельные железяки для каждой очереди существовать - это сравнимо с отдельным видеокартам для каждой очереди. Конечно ядра для обработки отдельно вершинных, пиксельных шейдеров и прочего организуются по разному и могут быть отдельными, но все же конвейер команд один, насколько я помню. Или это фишка видеокарт, которые могут запоминать отдельное количество состояний на "поток", с которыми они выполняют команды.

#442
8:54, 6 сен. 2021

foxes
>Чтоб такое обслужить там должны быть отдельные железяки для каждой очереди
Да ну? А что бы процессор обслуживал треды видимо нужно по отдельной железяке для каждого треда.

#443
9:19, 6 сен. 2021

Вообщето async compute появился на АМД gcn и PS4, для этого они добавили хардварные async compute engine.
Если бы можно было софтварно делать то же самое, то никто бы не усложнял железо.

#444
(Правка: 11:27) 10:41, 6 сен. 2021

san
> А что бы процессор обслуживал треды видимо нужно по отдельной железяке для
> каждого треда.
К CPU мы имеем непосредственный доступ, а к видеокарте через конвейер/буфер команд и единственную шину данных. Параллелизм множества GPU ядер можно легко сравнить с векторным вычислением на одном ядре CPU. И вообще на этот твой тролинг я уже дал объяснение:
foxes
> Конечно ядра для обработки отдельно вершинных, пиксельных шейдеров и прочего
> организуются по разному и могут быть отдельными, но все же конвейер команд
> один, насколько я помню.
На процессоре видеокарты, как я уже сказал это может работать параллельно, но для того чтобы это начало работать нужно загрузить для этого кучу состояний и параметров для одного "потока" не параллельно.

#445
11:37, 6 сен. 2021

foxes
> Чтоб такое обслужить там должны быть отдельные железяки для каждой очереди существовать
Зачем отдельные железяки? Просто отдельные буферы на GPU для каждой очереди. А CPU к ним может по айдишникам обращаться.
> Конечно ядра для обработки отдельно вершинных, пиксельных шейдеров и прочего организуются по разному и могут быть отдельными, но все же конвейер команд один, насколько я помню
Это из какого года привет?) Как раз ядра пытаются делать одинаковыми, что бы они могли выполнять все и, следовательно, меньше простаивали. А вот уже команды для мультипроцессоров можно из нескольких очередей черпать.
Хотя это я все про десктоп, на мобилках вполне может быть такой бардак.

#446
11:42, 6 сен. 2021

san
> В DX12 три очереди, одна для комьюта вторая для графики и третья для копирования. Они все по идее могут выполняться одновременно.
В DX12 можно создать сколько угодно очередей, лишь бы было целесообразно. Три - это количество основных типов очередей, но только основных, на самом деле есть еще video encode/decode.

#447
(Правка: 12:02) 11:49, 6 сен. 2021

phridrich
> Как раз ядра пытаются делать одинаковыми, что бы они могли выполнять все и,
> следовательно, меньше простаивали.
Назначение может быть разным все зависит от архитектуры. Но все же какой смысл загружать 100 ядер задачей для compute шейдеров и 100 для обычных когда можно 200 с начало на compute выделить, а потом те же 200 для всего остального. Смысл тут появляется если кто-то хочет задействовать очень маленькое количество ядер для разных задач. При том что такие параллельные вещи могут происходит в одном условном потоке вулкана, для последовательных compute шейдеров каждый их которых загружает только 10-20 ядер.
phridrich
> А вот уже команды для мультипроцессоров можно из нескольких очередей черпать.
Можно или так и есть? Какой смысл городить отдельные буферы команды когда шина данных одна?
phridrich
> А CPU к ним может по айдишникам обращаться.
Это буферы состояний, которые еще на GL жили, конвейер команд (запросы CPU) все равно один. Не то что для приложения, для всех CPU процессов один на всех.

#448
(Правка: 17:24) 16:51, 6 сен. 2021

phridrich
> В DX12 можно создать сколько угодно очередей, лишь бы было целесообразно
Неверно. Можно создать сколько угодно CommandList'ов, но не очередей (CommandQueue). Очередей три, из них одна (графическая) универсальная а компьют и копи могут выполнять только соответствующие операции.

>Какой смысл городить отдельные буферы команды когда шина данных одна?
При чем тут шина? Командные листы записываются в очередь. Записываются последовательно, в порядке поступления. Сама очередь размещается на CPU. Потом весь этот буфер (CommandQueue) одним чохом передается на GPU и начинает там выполняться. Шина используется для передачи данных ДО начала работы карты.

foxes
> CPU мы имеем непосредственный доступ, а к видеокарте через конвейер/буфер команд и единственную шину данных.
Распределение физических ресурсов между тредами (или очередями в GPU) делает драйвер. Никакого "непосредственного доступа" к процессу переключения процессорных ядер выполняемый тред не имеет.

>для того чтобы это начало работать нужно загрузить для этого кучу состояний и параметров для одного "потока" не параллельно.
Загрузка параметров (подготовка данных) делается на CPU паралельно выполнению очереди GPU. Моя аппликация постоянно работает с двумя очередями, я уже постил картинки - лень искать. Для этого не нужно "загружать кучу состояний и параметров" по ходу работы GPU - они уже там. Всю работу по переключению ядер GPU берет на себя драйвер. Поскольку у карты несколько тысяч ядер но их количество явно меньше числа пикселей, то обработка все равно идет последовательно и какая то часть ядер всегда простаивает. При выполнении двух очередей одновременно, загрузка ресурсов происходит более равномерно, поэтому параллельная работа выполняется быстрее чем последовательный запуск очередей. Грубо говоря между обработкой пикселей вклинивается компьют или копи. Этот процесс программист не контролирует.

#449
17:31, 6 сен. 2021

foxes
> Но все же какой смысл загружать 100 ядер задачей для compute шейдеров и 100 для обычных когда можно 200 с начало на compute выделить, а потом те же 200 для всего остального.
Во-первых, ядра при благоприятных условиях могут хранить несколько контекстов одновременно, и выполнять их по очереди какой смогут.
Во-вторых - задачи, что 3D, что компьют, могут иметь разную природу. Например, одна задача может быть обычным блиттингом, и, следовательно, почти полностью ограничиваться операциями с памятью, другая - какими-то тяжелыми вычислениями, которым необходимы арифметические устройства, третья - какой-нибудь графикой, в в которой не вывозят растеризаторы. И разные очереди нужны для того, что бы дать ядрам разноплановые нагрузки, чтобы подсистемы памяти/вычислений/растеризации/etc меньше простаивали.

san
> Можно создать сколько угодно CommandList'ов, но не очередей (CommandQueue).
Да что ты говоришь. И что конкретно помешает мне создать 4 очереди (кстати, я только что это сделал)?
> Очередей три, из них одна (графическая) универсальная а компьют и копи могут выполнять только соответствующие операции.
Компьют может выполнять не только компьют, но и копи.
> Поскольку у карты несколько тысяч ядер но их количество все равно меньше числа пикселей, то обработка все равно идет последовательно и какая то часть ядер всегда простаивает.
Точно все правильно написал?

Страницы: 127 28 29 30 31 32 Следующая »
ПрограммированиеФорумГрафика