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

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

Страницы: 1557 558 559 560578 Следующая »
#8355
(Правка: 8:00) 8:00, 31 мар. 2021

innuendo
> тестил ?
Нет, меня интересует некий усредненный результат. А то может на картах c GDDR3 будет одно, а на GDDR6 - совсем другое. У меня нет всей линейки карт для теста.


#8356
8:13, 31 мар. 2021

MikeNew
> А то может на картах c GDDR3 будет одно, а на GDDR6 - совсем другое
больше нечем заняться?

#8357
8:16, 31 мар. 2021

MikeNew
ну так если у тебя в одном варианте на каждый меш по одному мапу/анмапу, а в другом варианте этого нет, то сам-то как думаешь? ясное дело, на 50 инстансах это никакой роли не играет, а если у тебя их 100000 (частицы, например)?

#8358
8:23, 31 мар. 2021

Suslik
> ну так если у тебя в одном варианте на каждый меш по одному мапу/анмапу, а в
> другом варианте этого нет, то сам-то как думаешь? ясное дело, на 50 инстансах
> это никакой роли не играет, а если у тебя их 100000 (частицы, например)?
Ок, что-то подобное я и предполагал - мапы/анмапы достаточно дороги чтобы при большом количестве свести к нулю профит от экономии на размере копируемой памяти. Спасибо.

#8359
(Правка: 8:27) 8:26, 31 мар. 2021

MikeNew
> при большом количестве свести к нулю профит от экономии на размере копируемой памяти
какой профит от размера? нет никакой разницы с точки зрения объёма памяти, скопировать 100500 мелких буферов под одному на объект, либо скопировать один буфер, состоящий из 100500 элементов по одному на объект. только для реализации первого понадобится 100500 map/unmap, а для второго — один.

#8360
9:03, 31 мар. 2021

MikeNew
я тестил, получил около 15% буста. map/unmap лучше делать 1 раз константный буфер в пределах очереди.

#8361
9:17, 31 мар. 2021

Suslik
> какой профит от размера? нет никакой разницы с точки зрения объёма памяти,
> скопировать 100500 мелких буферов под одному на объект, либо скопировать один
> буфер, состоящий из 100500 элементов по одному на объект. только для реализации
> первого понадобится 100500 map/unmap, а для второго — один.
Вообще-то в примере речь шла о 100500/2 map/unmap. 100 объектов за один раз, против 50 объектов, но кусочками по 1-ому объекту.

#8362
14:43, 31 мар. 2021

MikeNew
> для какой-то части этих мешей (например, для пятидесяти мешей) мне юниформы обновлять не надо
Можно в процессе обновления сцены определять диапазон индексов изменившихся мешей и мапить только часть буфера с обновляемыми данными. Тогда, как и в случае обновления всего буфера, будет не более одного map-unmap на кадр, но данных, в среднем, копировать придётся меньше.

#8363
(Правка: 15:39) 15:35, 31 мар. 2021

MikeNew
Зачем столько map, вообще достаточно одного после создания буффера? Гугли Persistent Mapping

#8364
19:17, 31 мар. 2021

Хз, было ли:
Understanding Vulkan Synchronization

#8365
5:23, 1 апр. 2021

Andrey
> я тестил, получил около 15% буста. map/unmap лучше делать 1 раз константный
> буфер в пределах очереди.
IBets
> Зачем столько map, вообще достаточно одного после создания буффера? Гугли
> Persistent Mapping
Так и сделал, работает, слои молчат.
И копировать можно буфер разного размера, главное не больше выделенного, отлично.

#8366
12:14, 6 апр. 2021

> А почему в MoltenVk сделано 4 графические очереди с разным queue family?
Нашел ответ на свой вопрос

The command buffer can only be committed for execution on the command queue that created it.

То есть это ограничение метал апи. В вулкане и дх можно создавать очереди с одинаковым queue family / queue type и выполнять командные буферы в разных очередях в пределах одной queue family.

#8367
(Правка: 22:22) 22:22, 6 апр. 2021

Я неправ или нашёл ошибку в NVidia ray tracing samples? Барьер выставляется на запись из трансфера и начало чтения ускоряющей структурой.

    // Make sure the copy of the instance buffer are copied before triggering the
    // acceleration structure build
    VkMemoryBarrier barrier{VK_STRUCTURE_TYPE_MEMORY_BARRIER};
    barrier.srcAccessMask = VK_ACCESS_TRANSFER_WRITE_BIT;
    barrier.dstAccessMask = VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR;
    vkCmdPipelineBarrier(cmdBuf, VK_PIPELINE_STAGE_TRANSFER_BIT, VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_NV,
                         0, 1, &barrier, 0, nullptr, 0, nullptr);


    // Build the TLAS
    vkCmdBuildAccelerationStructureNV(cmdBuf, &m_tlas.asInfo, m_instBuffer.buffer, 0, VK_FALSE, m_tlas.as.accel,
                                      nullptr, scratchBuffer.buffer, 0);

Вместо VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR должен быть флаг VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR

#8368
(Правка: 7:07) 7:06, 7 апр. 2021

v1c
никогда не трогал vulkan raytracing, но название стадии VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_NV какбе говорит "build", то есть оно, очевидно, должно писать, а не читать ускоряющую структуру, поэтому нужно сделать память видимой для записи. так что я не вижу проблемы.

#8369
7:17, 7 апр. 2021

Suslik
> нужно сделать память видимой для записи
это как?
я знаю только: сделать доступной после записи (flush), сделать видимой для чтения (invalidate)

Страницы: 1557 558 559 560578 Следующая »
ПрограммированиеФорумГрафика