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

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

Страницы: 127 28 29 30 31 32 Следующая »
#450
(Правка: 18:47) 18:29, 6 сен. 2021

san
> (или очередями в GPU) делает драйвер.
Вот это точно нет. Драйвер не управляет ни чем кроме передачи и организации данных (На своей же стороне) и потока команд (запросов) от СPU на уровне выдуманного контекста не относящегося к GPU ни какого отношения.
san
> Всю работу по переключению ядер GPU берет на себя драйвер.
Абсолютно точно нет. Есть одна единственная команда отреднерить вершины, которой передаются непосредственно адреса с шейдерными программами и все прочим, на стороне видеокарты, в том числе загружаются дополнительные параметры или передается адрес на сохраненные на стороне видео карты, все остальное делает видеокарта! О каких то там ядрах драйвер вообще не имеет представление.
san
> Для этого не нужно "загружать кучу состояний и параметров" по ходу работы GPU -
> они уже там.
Молодец прочитал то что я уже написал
foxes
> Это буферы состояний, которые еще на GL жили, конвейер команд (запросы CPU) все
> равно один. Не то что для приложения, для всех CPU процессов один на всех.
san
> Загрузка параметров (подготовка данных) делается на CPU паралельно выполнению
> очереди GPU.
Ну ты мне еще расскажи как загружаются данные, под соусом, что ядрами видеокарты можно управлять со стороны СPU. Троло-ло.
phridrich
> Во-первых, ядра при благоприятных условиях могут хранить несколько контекстов
> одновременно, и выполнять их по очереди какой смогут.
Ядра вообще не хранит никакие контексты. Бред уже какой то.


#451
(Правка: 19:30) 19:30, 6 сен. 2021

foxes
> Ядра вообще не хранит никакие контексты.
Да, это куцая формулировка, но так-то на GPU и ядер нет, есть треды в мультипроцессорах. Так вот эти мультипроцессоры имеют регистровый файл, и в этот регистровый файл может влезать несколько контекстов выполнения шейдера (содержимое регистров, instruction pointer и что там еще). И храня эти контексты, мультипроцессор может выполнять их по очереди, обеспечивая при возможности latency hiding инструкций.

#452
(Правка: 20:07) 19:40, 6 сен. 2021

phridrich
Ну знаешь, так можно и CPU ядро и все его регистры начиная от регистров состояния процессора, до регистров общего назначения с таблицей памяти назвать контекстом и нафантазировать на основе этого кучу теорий. А по сути ядро работает с теми значениями регистров которые у него есть и не более. Контекст, часть параметров которого передается при рендеренге от драйвера через комманды командного буфера, и регистры ядер GPU это не одно и тоже.
Тот же самый контекст хранимый на стороне GPU как и любые другие данные текстура или вершины, для самой видеокарты безлики до тех пор пока ссылка на них не будет отправлена как соответствующий параметр в команде.

#453
20:03, 6 сен. 2021

phridrich
> И что конкретно помешает мне создать 4 очереди
Буфера создать можешь, но одновременно выполнить две однотипные очереди - нет. Поэтому в данный момент времени могут выполняться только три очереди разных типов.

>Точно все правильно написал?
А у тебя есть сомнения?

#454
(Правка: 20:34) 20:15, 6 сен. 2021

foxes
> Драйвер не управляет ни чем кроме передачи и организации данных
Драйвер видеокарты включает все, от транслятора до планировщика. У тебя какое то первобытное понятие об этой компоненте. Современные ОС несколько отличаются от MS-DOS.

>еще расскажи как загружаются данные, под соусом, что ядрами видеокарты можно управлять со стороны СPU.
Что за бред ты пишешь? Я как раз объясняю что CPU не может управлять ядрами видеокарты. Точно так же как тред на CPU не может управлять ядрами процессора. Это делается на уровне драйвера (системы) а не на уровне программиста. Данные загружаются в память карты, это никак не связано с "ядрами". Что за мешанина у вас в голове?

>Есть одна единственная команда отреднерить вершины, все остальное делает видеокарта!
Это пять баллов! Видеокарта это ЖЕЛЕЗО, что бы она что-то "делала" нужен СОФТ. Так вот этот софт называется драйвером. Доступно излагаю? Программа передает карте последовательность команд (CommandQueue), далее ДРАЙВЕР преобразует их в микрокод, управляет респределением по корам и т.д.

#455
(Правка: 20:17) 20:15, 6 сен. 2021

foxes
> так можно и CPU ядро и все его регистры начиная от регистров состояния процессора, до регистров общего назначения с таблицей памяти назвать контекстом
Состояние регистров CPU при выполнении некоторого потока вообще-то и называется контекстом. Никогда не слышал про "переключение контекста" что-ли?
> нафантазировать на основе этого кучу теорий. А по сути ядро работает с теми значениями регистров которые у него есть и не более.
По сути ядра нет, есть тред. И да, работает оно с тем что есть, но быть у него может несколько контекстов. Если не веришь - можешь открыть мануал и прочитать.

#456
21:57, 6 сен. 2021

san
> Буфера создать можешь, но одновременно выполнить две однотипные очереди - нет.
Очереди в принципе нельзя выполнить, ни одновременно, ни последовательно. То что ты называешь "буферами" - это и есть очереди в DirectX 12, и их может быть сколько угодно. А вот аппаратных очередей - да, фиксированное количесво, но все равно не три - еще может быть кодирование/декодирование видео.
> А у тебя есть сомнения?
Ну давай посмотрим, пусть у тебя есть видеокарта на 5000 ядер, на которой ты запускаешь +- равномерную нагрузку, разбитую на 2000000 пикселей. Объясни пожалуйста необремененному многолетним опытом человеку, когда и сколько ядер будет простаивать и почему.

#457
22:09, 6 сен. 2021

phridrich
> когда и сколько ядер будет простаивать и почему.
Каждое чтение текстуры вызывает простой, особенно если не из кэша читается.

#458
(Правка: 7 сен. 2021, 0:40) 23:43, 6 сен. 2021

phridrich
> Очереди в принципе нельзя выполнить, ни одновременно, ни последовательно.
Правда что ли?  ID3D12CommandQueue::ExecuteCommandLists

>То что ты называешь "буферами" - это и есть очереди в DirectX 12,
Я не называю очереди буферами. Я говорю что ты можешь создать несколько объектов (массивов, буферов - назови как угодно) используя ComPtr<ID3D12CommandQueue>.  Но это просто структура в памяти CPU с интерфейсом ID3D12CommandQueue.

> Ну давай посмотрим, пусть у тебя есть видеокарта на 5000 ядер, на которой ты запускаешь +- равномерную нагрузку, разбитую на 2000000 пикселей. Объясни пожалуйста необремененному многолетним опытом человеку, когда и сколько ядер будет простаивать и почему.

Необремененному сложно. А если человек разбирается в кухне, то он знает, что пиксели рассположенные в разных частях экрана могут вычисляться за очень разное время. "Равномерная нагрузка" это заливка экрана одним цветом, но реальная картинка чаще всего несколько сложнее. Поэтому часть тредов могут завершить работу намного раньше других и при всех усилиях планировщика загрузить все коры на 100% в течении всего времени рендера нереально. В эти "дырки" планировщик может засунуть команды из других очередей. В реальных условиях (на моей аппликации) выигрышь невелик - 15-20%, но и это лучше чем ничего. На других примерах экономия может быть больше (или меньше).

#459
1:40, 7 сен. 2021

san
> Правда что ли? ID3D12CommandQueue::ExecuteCommandLists
Нормальные люди здесь видят выполнение списков команд, а не выполнение очереди, но сквозь призму многолетнего опыта тут конечно всякое можно увидеть.
> Я не называю очереди буферами. Я говорю что ты можешь создать несколько объектов (структур, буферов - назови как угодно) используя ComPtr<ID3D12CommandQueue>.
Короче ты называешь объект класса ID3D12CommandQueue как угодно, только не очередью. Наверное командная коммуникация с тобой - одно удовольствие.
> А если человек разбирается в кухне, то он знает, что пиксели рассположенные в разных частях экрана могут вычисляться за очень разное время.
Ну если у тебя тривиальный реймаршер, то конечно нагрузка неравномерная. Только вот сознательные люди таких нагрузок обычно стараются избегать. Получается не всегда, но как минимум реальная картина подобной мутью не ограничивается.
> Поэтому часть тредов могут завершить работу намного раньше других и при всех усилиях планировщика загрузить все коры на 100% в течении всего времени нереально.
А теперь повторяем все заново. Ты сказал, что "какая то часть ядер всегда простаивает". Я сказал что это не так,  на что ты мне пытаешься доказать что ядра GPU не всегда полностью загружены. ОК, я согласен, что часть ядер может иногда простаивать, но ты сказал что так происходит всегда.
> В реальных условиях (на моей аппликации) выигрышь невелик - 15-20%, но и это лучше чем ничего.
Это как раз немало, яркая демонстрация неоптимизированости твоего приложения.

#460
(Правка: 3:59) 2:57, 7 сен. 2021

phridrich
> Нормальные люди здесь видят выполнение списков команд, а не выполнение очереди
А списки команд поставленные друг за другом это значит не очередь? Хорошо, тогда что бы тебе понятно было:
"Списки команд" (CommandList) расположены на CPU.  Сами по себе они (команды) к видеокарте отношения не имеют - это байткод. Интерфейс ID3D12CommandQueue с помощью метода ExecuteCommandLists передает эти команды на GPU где из них формирует ОЧЕРЕДЬ микроинструкций. Выполнением которых и распределением команд по физическим ресурсам занимается драйвер. Стало понятнее или разжевывать дальше?

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

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

>Это как раз немало, яркая демонстрация неоптимизированости твоего приложения.
Видишь ли, у меня в фоновом режиме выполняются тяжёлые компьют-шейдера. Время работы шейдера - от 20 до 150 мс в зависимости от положения тайла. Общее время рассчета - до 5 секунд. В то же самое время мне нужно каждые 11 мс выводить довольно сложную картинку которая зависит от текущего положения головы. Тормоза недопустимы поскольку это VR. Значит нужно каждые 11 мс останавливать компьют-шейдер, запускать графическую очередь, а потом возвращаться к расчёту компьюта. А теперь умник расскажи, как мне решить эту задачу "оптимально" без параллельной работы очередей. Хочу послушать мнение специалиста.

#461
5:38, 7 сен. 2021

san
> А теперь умник расскажи, как мне решить эту задачу "оптимально" без
> параллельной работы очередей. Хочу послушать мнение специалиста.

san
> в фоновом режиме выполняются тяжёлые компьют-шейдера. Время работы шейдера - от
> 20 до 150 мс в зависимости от положения тайла. Общее время рассчета - до 5
> секунд.

san
> Тормоза недопустимы поскольку это VR

а у человека еще и ОБС(захват экрана, создающий еще одну камеру в ВР) запущен
и все дефолтные для ВР оверлеи, и еще Юнити поверх для замены 3Д-аватара

и твои 5 сек компут шейдера превращаются в 25 сек и вешают намертво все что рендерится за временем твоего кадра, и потом люди жалуются "а почему ВР так тормозит на моей Нвидиа 3090"
для удобства пользователя в ВР надо рассчитывать на в идеале на 25% от макс нагрузки на видеокарту, максимум на 50%
если тебе нужно больше - оптимизируй

#462
12:21, 7 сен. 2021

san
> А списки команд поставленные друг за другом это значит не очередь?
А, то есть объект класса ID3D12CommandQueue очередью называть не кошерно, а вот массивчик комманд листов - это очередь в чистом виде? Весело с тобой.
> Так происходит всегда, но в зависимости от задачи этот простой может меняться от едениц процентов до нескольких раз.
Во-первых, можешь, пожалуйста, разжевать неопытному, как это простой может меняться от единиц процентов до нескольких раз. "Нескольких раз" - это сколько процентов от ядер GPU?
Во-вторых, тот простой, о котором ты видимо говоришь, может происходить лишь в конце выполнения задачи, когда некоторые ядра еще работают, а некоторые уже закончили работу, и новой для них нет (а может и не происходить, если есть новая задача и нет каких-либо причин ожидать текущую перед началом работы над следующей). А ты сказал, что "часть ядер всегда будет простаивать". Всегда - значит в любой момент времени.
> Время рассчета пикселя неба и пикселя блика в стеклянной посуде могут различаться на порядок и более.
А считать небо и блики в одном шейдере тебе многолетний опыт подсказал?
> расскажи, как мне решить эту задачу "оптимально" без параллельной работы очередей.
А где я говорил, что тебе не нужно использовать очереди? Используй на здоровье. Я говорил о том, что  выигрыш в 15%-20% - это примерно в два раза больше максимума того что обычно получают нормальные люди на реальных проектах - загугли любую презенташку про то как какой-то геймдев перешел на DirectX 12/Vulkan. А это означает, что ты загрузил свои ядра примерно в 2 раза хуже чем они - читай нагрузка неоптимизирована. И не надо тут рассказывать какое у тебя уникальное приложение, им тоже приходится делать SSR и подобные неравномерные дела.
А если хочешь что-бы кто-то рассказал как решать твою задачу - так напиши ТЗ, у телепатов каникулы закончились.

#463
(Правка: 8 сен. 2021, 0:02) 15:22, 7 сен. 2021

phridrich
> тот простой, о котором ты видимо говоришь, может происходить лишь в конце выполнения задачи
Да ну? Похоже ты не в курсе что количество ядер сильно меньше количества пикселей и одно ядро за время рендера обрабатывает множество пикселей. Вызываясь последовательно и выполняя операции за разное время.

>А считать небо и блики в одном шейдере тебе многолетний опыт подсказал?
Что за глупость сказал? В том то и дело что разные участки изображения выводятся РАЗНЫМИ шейдерами. Которые выполняются за разное время. Но делают это те же самые ядра в процессе выполнения одной и той же очереди команд.

>Я говорил о том, что выигрыш в 15%-20% - это примерно в два раза больше максимума того что обычно получают нормальные люди на реальных проектах - загугли любую презенташку про то как какой-то геймдев перешел на DirectX 12/Vulkan
??? Причем тут переход на DX12? Речь шла об выигрыше в скорости при использовании параллельного выполнения двух очередей по сравнению с их последовательным вызовом. Выигрышь получается из-за лучшей загрузки коров что я и пытался тебе втолковать. Похоже безуспешно.

melvy
> твои 5 сек компут шейдера превращаются в 25 сек и вешают намертво все что рендерится за временем твоего кадра
Ты ничего не понял. В том то и дело, что у меня компьют шейдер НЕ вешает рендер. И это достигается использованием параллельной работы разных очередей. Никак по другому это не решается, поскольку на GPU нет прерываний.

#464
1:57, 8 сен. 2021

san
> Похоже ты не в курсе что количество ядер сильно меньше количества пикселей и одно ядро за время рендера обрабатывает множество пикселей.
Похоже ты так и не научился читать то что тебе пишут. Мои слова несколькими комментариями ранее:
пусть у тебя есть видеокарта на 5000 ядер, на которой ты запускаешь +- равномерную нагрузку, разбитую на 2000000 пикселей.
> Что за глупость сказал? В том то и дело что разные участки изображения выводятся РАЗНЫМИ шейдерами. Которые выполняются за разное время. Но делают это те же самые ядра в процессе выполнения одной и той же очереди команд.
На это даже не знаю что ответить. Дело в том, что видеокарты делали люди сильно умнее тебя и меня, и они позаботились о том, чтобы даже откровенный быдлокод шедулился наилучшим образом. Если ты выполняешь один диспатч для одной половины экрана и другой диспатч для второй - то тебе без разницы, насколько различаются их шейдеры, так как пикселей в половине экрана все равно значительно больше чем ядер GPU, и все нормально распараллелится. Даже если ты сделаешь диспатч на малую часть экрана, где пикселей меньше чем ядер - все равно это не приговор, видеокарта посмотрит на следующие задачи в комманд листе и если они готовы к выполнению - запустит их. Что ты можешь сделать - так это понатыкать барьеров и семафоров, чтобы следующие задачи не могли начать выполняться - тогда да, будут проблемы с параллелизмом. Но обычно можно изменить алгоритм так, чтобы избавиться от подобной ситуации.
> ??? Причем тут переход на DX12?
При том, что если бы ты вместо того, чтобы сидеть и кичиться своими годами профанации, взял бы да погуглил что говорят компетентные в сфере люди, ты бы обнаружил немало презентаций gamedev-компаний на тему того, как они используют у себя DX12/Vulkan, и что зачастую в таких презентациях рассказывают в том числе и про async compute. Но ты видимо ни одной из них не видел - зачем искать и перенимать чужие знания, если можно сварганить на коленке дубовое решение нужной задачи и считать его самым лучшим просто потому что оно сделано тобой? Собственно, все сходится - одинокий волк, который называет массив комманд листов очередью и гордится реймаршером, выполняющимся 5 секунд.

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