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

Vulkan API (вышел!) (731 стр)

Страницы: 1730 731 732 733739 Следующая »
#10950
12:17, 26 фев 2024

prowkan

А зачем это всё надо? В D3D12 достаточно указать предпочитаемый пул
(оперативная память или видеопамять) и режим доступа со стороны центрального
процессора (без доступа, Write Combined, Write Back) и всё, никаких мучений с
разными типами и прочим бредом.

Так в VMA все это есть.

То, что меньше позволяет производителям железа, гораздо больше фиксированных ограничений (количество RT, выравнивания и прочего), проще писать, потому что надо меньше запрашивать данных об оборудовании. Vulkan же позволят вендорам слишком много.

Ограничения в DX12 фиксированы обычно на больших значениях чем основная масса железа имеет на Vulkan, если речь о desktop-level. Поэтому можно просто захардкодить везде лимиты из DX. А если речь о мобильных то уж извините, DX на них нет вообще

#10951
12:28, 26 фев 2024

CatsCanFly
А на Линукс или макос есть директ ? Какая жаль

#10952
12:37, 26 фев 2024

innuendo
Линукс + графика мало кому нужно, а на Мак и Vulkan нативно нет

#10953
13:30, 26 фев 2024

s3dworld
> А почему прекрасным? Что в нём такого?
ну каку как рендер посложнее напишешь все станет ясно. На вскидку -

-более сложная работа с очередями
-выбор устройства(рекомендации не все расширения включать - hint драйверу)
-лишняя абстракция - VkFrameBuffer
-дескрипторы - VkPipelineLayout + VkDescriptorSetLayout - в Direct3D12 обошлить ID3D12RootSignature
-более сложная синхронизация

Я фанат Vulkan, но увы, Direct3D12 проще кода писать чуть меньше. Да, на мобилках нету Direct3D12,  Vulkan выигрывает,  но проигрывает Metal(где MeshShaders, Tile Shading ?)
CatsCanFly
> а на Мак и Vulkan нативно нет
там есть Metal и он хорош и сейчас есть C++ интерфейс к нему

#10954
13:39, 26 фев 2024

Есть анрил юнити ...а писать самому  это некоммерческий вариант :)

#10955
15:09, 26 фев 2024

Andrey
> -дескрипторы - VkPipelineLayout + VkDescriptorSetLayout - в Direct3D12
> обошлить ID3D12RootSignature
Так дескриптор сеты проще как по мне чем таблицы дескрипторов в D3D12. В D3D надо писать свой аллокатор таблиц из descriptor heap а в vulkan хотя бы это скрыто от программиста за vkDescriptorAllocator

> -более сложная синхронизация
В итоге D3D пришел к той же модели что в Vulkan, просто позже: https://microsoft.github.io/DirectX-Specs/d3d/D3D12EnhancedBarriers.html
А vulkan в свою очередь перешел на timeline semaphore что полный аналог fence в d3d

#10956
15:14, 26 фев 2024

CatsCanFly
Т. е. то, что в D3D12 нужно самому писать аллокатор таблиц, а в Vulkan это скрыто, то это плохо, а то, что в Vulkan нужно выбирать между разными типами памяти, а в D3D12 это скрыто - это хорошо?
И да, в итоге Vulkan пришёл к той же модели, что и в D3D12, просто позже: https://www.khronos.org/blog/vk-ext-descriptor-buffer

#10957
15:37, 26 фев 2024

prowkan
Можно ничего не выбирать а просто пользоваться VMA.
vk-ext-descriptor-buffer это все же для другого, с ним можно например копировать дескрипторы прямо из шейдеров, в D3D так в принципе сделать нельзя насколько понимаю

#10958
19:19, 26 фев 2024

А вот смотрите. Правильно ли я понимаю. Вот возьмём Vulkan. И у нас могут получиться такие ситуации:

1. У устройства (GPU) нет собственной памяти.
2. У устройства (GPU) есть собственная память.

Я так понимаю, первый случай для интегрированных видеокарт, а второй - дискретных. При первом случае память и так всегда будет доступна для хоста (CPU). Поэтому достаточно просто идёт работа с ресурсами. Например, выделил память в такой куче (ну там через тип памяти). Создал буфер для вершин. Связал и вызвал Map().

А вот если второй случай, то обязательно (а как иначе?!) будет ещё такой тип памяти, который принадлежит устройству, но в тоже время виден и хосту. Потому что обязательно у устройства будет тип памяти, который не виден хосту. И я так понимаю, если хост видит, то такой памяти мало (проверял на 3 видеокартах, порядка 200-300 МБ). А то, что хост не видит, может быть много. Получается, что при таком варианте нужно выделять память под один ресурс два раза. Один раз чтобы это было локально для устройства. А другой раз, чтобы хост имел возможность закинуть данные через Map(). Когда всё создано, связано и закинуто, то тогда для очереди с VK_QUEUE_TRANSFER_BIT можно дать указание перенести данные в ту память, которая максимально быстро работает с устройством. Ошибся где-нибудь?

Хоть тема про Vulkan, но всё же тут и знающие по Direct3D 12 сидят. Так что же в Direct3D 12?! Есть ID3D12Device::CreateCommittedResource(), который для каждого вызыва создаёт свою кучу. Не очень. А есть ID3D12Device::CreateHeap(), где уже можно создать кучу, а затем, через ID3D12Device::CreatePlacedResource(), в одну кучу много ресурсов размещать. Есть ещё и резервирование ресурсов, но это ладно. Я вот просто пока не понял как они там данные перемещают. В примере используется ID3D12Device::CreateCommittedResource(), который использует D3D12_HEAP_TYPE_UPLOAD. Но что-то я не видел (я про официальные примеры от Microsoft, прям по выводу треугольника) чтобы они там отправляли данные в другой тип памяти. Они там что, тупо рендерят треугольники из медленной памяти? Ну и собственно, heap type называется D3D12_HEAP_TYPE_UPLOAD. А если видеокарта интегрированная? Блин, что-то запутаться можно. Кажется что в Vulkan более понятно.

#10959
19:26, 26 фев 2024

s3dworld
> А вот если второй случай, то обязательно (а как иначе?!) будет ещё такой тип
> памяти, который принадлежит устройству, но в тоже время виден и хосту.
Не всегда, на NVIDIA в Vulkan долгое время не было памяти типа DEVICE_LOCAL | HOST_VISIBLE
> Я вот просто пока не понял как они там данные перемещают.
> Блин, что-то запутаться можно. Кажется что в Vulkan более понятно.
Что там не понятного? Создать буфер в UPLOAD куче, сделать Map, заполнить буфер данными, создать ресурс в DEFAULT куче, скопировать из буфера в UPLOAD куче в ресурс в DEFAULT куче.
Всё понятно и всё логично, причём используются удобные перечисления типов памяти, в отличие от этого маразма в Vulkan, где номера разных типов могут быть отличаться на разных видеокартах, и приходится учитывать это при разработке.

#10960
19:31, 26 фев 2024

prowkan
> Не всегда, на NVIDIA в Vulkan долгое время не было памяти типа DEVICE_LOCAL | HOST_VISIBLE
А как тогда загружать данные в DEVICE_LOCAL? Напрашивается что мы просто в системную память хоста что-то ложим, а устройство уже это себе копирует. Но я что-то ничего такого не видел (функции).

prowkan
> Что там не понятного?
Да не понятно то, что в Vulkan всегда можно узнать что есть и какого размера. А в Direct3D 12 всё более абстрактно что ли. Пугает что в любой момент что-то отвалится может.

#10961
19:33, 26 фев 2024

s3dworld
> А как тогда загружать данные в DEVICE_LOCAL?
Путём копирования из HOST_VISIBLE в DEVICE_LOCAL.
> Да не понятно то, что в Vulkan всегда можно узнать что есть и какого размера.
Так и в D3D12 можно узнать, что есть и какого размера.
> Пугает что в любой момент что-то отвалится может.
В Vulkan отвалится гораздо быстрее.

#10962
19:39, 26 фев 2024

Ну а с синхронизацией как дела обстоят у этих двух API? В Vulkan там жуть. То, что команды могут завершиться в разном порядке - это логично. А вот то, что они и запуститься могут не в том порядке, в котором их воткнул в буфер - это пипец. Ещё как-то синхронизировать нужно. А как дела обстоят в Direct3D 12? Там тоже такое же поведение?

#10963
6:55, 27 фев 2024

s3dworld
Да, в примере д3д12 от Майкрософт треугольник рисуется прям из аплод хипа. В вулкане тоже так можно. Да, каждый кадр будут данные гоняться по PCIex шине. Ну и что, для динамической геометрии это норм.

#10964
11:35, 27 фев 2024

s3dworld
> А как дела обстоят в Direct3D 12? Там тоже такое же поведение?
Вулкан и дх12 внутри работают одинаково, отличаются только внешним апи.

Страницы: 1730 731 732 733739 Следующая »
ПрограммированиеФорумГрафика