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

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

Страницы: 1556 557 558 559578 Следующая »
#8340
9:27, 25 мар. 2021

/A\
> Вот еще
спасибо поизучаю.


#8341
14:58, 25 мар. 2021

А почему в MoltenVk сделано 4 графические очереди с разным queue family? Тогда как на андроиде одна queue family и 2 софтварные очереди.
Это в метале так работает шаринг ресурсов между очередями, что нужно эмулировать это через queue ownership transfer ?

#8342
15:39, 25 мар. 2021

Вот еще что нашел:
https://community.arm.com/developer/tools-software/graphics/b/blo… ulkan-on-mali

Anything related to VERTEX_SHADER_BIT or COMPUTE_SHADER_BIT goes into the vertex/tiling/compute hardware queue, and FRAGMENT_SHADER_BIT and friends go into the fragment hardware queue.

Это метал. Тут говорится про 3 очереди - по одной на каждый тип шейдера (вершинный, фрагментный, компьют)
https://developer.apple.com/videos/play/wwdc2020/10632/

#8343
17:45, 25 мар. 2021

/A\
> Тут говорится про 3 очереди - по одной на каждый тип шейдера (вершинный,
> фрагментный, компьют)

жуть какая-то - и ты ещё жалуешся на dx12 ?

#8344
19:49, 25 мар. 2021

innuendo
> жуть какая-то - и ты ещё жалуешся на dx12 ?
Так это скрыто, наружу у них видно только 4 графические очереди, но если хочешь оптимизировать, то надо учитывать как оно внутри работает и не синхронизировать вершинный шейдер с фрагментным или компьютом, чтоб не было ожидания в других очередях.
У меня больше вопрос в том почему MoltenVk определяет их как разные queue family, что требует немного больше работы по передаче ресурсов между очередями.

#8345
21:49, 25 мар. 2021

innuendo
> и ты ещё жалуешся на dx12 ?
Если ты фанат дх12, то раскажи про resource state promotion and decay

#8346
9:38, 26 мар. 2021

/A\
> > и ты ещё жалуешся на dx12 ?
> Если ты фанат дх12

фанат это у нас Andrey

на фоне сабжа dx12 супер стабилен и проще - хотя только на декстопах есть :)

#8347
20:32, 30 мар. 2021

А кто уже использовал timeline semaphore? Желательно не только на домашних проектах.

В описании vkGetSemaphoreCounterValue нет никаких гарантий по синхронизации с гпу и про доступ к памяти, как это сделано для vkWaitForFences. С другой стороны появиласть такая надпись:

Signaling a fence and waiting on the host does not guarantee that the results of memory accesses will be visible to the host, as the access scope of a memory dependency defined by a fence only includes device access. A memory barrier or other memory dependency must be used to guarantee this.

Но есть такая гарантия
The first access scope includes all memory access performed by the device.

В итоге timeline semaphore это замена в том числе и fence или только замена бинарных семафоров, а для переиспользования ресурсов надо ждать fence?

#8348
21:23, 30 мар. 2021

/A\
Посмотри мой pull request в DiligentCore, я через таймлайн семафор организовал IFence. Хз насколько верно, уже не помню деталей.
Выпилить до конца бинарные семафоры не получится, так как SwapChain не работает с таймлайн семафорами(возможно в будущем добавят)

#8349
(Правка: 21:39) 21:37, 30 мар. 2021

IBets
Меня интересует какие гарантии дает документация по вулкану. То что таймлайны работают у всех кто их использовал еше ни о чем не говорит. Почти у всех проектов что я видел есть проблемы с правильной расстановкой синхронизаций, но они как-то работают. А рано или поздно обновят драйвера и что-то перестанет работать.

upd: И к тому же у меня нет девайса с некогерентной памятью, чтоб протестировать самые спорные ситуации.

#8350
(Правка: 7:02) 6:58, 31 мар. 2021

Возник вопрос.

Вот, допустим, обновляю я юниформы для сотни мешей:

  
  #define MAX_NUMBER_MODELS 100
  dynamicAlignment_Model = 1024;

  void* data;
  vkMapMemory(logicalDevice, uniformBuffersMemory_Models[currentImage], 0, VK_WHOLE_SIZE, 0, &data);
  memcpy(data, modelUBO.model, MAX_NUMBER_MODELS * dynamicAlignment_Model);
  vkUnmapMemory(logicalDevice, uniformBuffersMemory_Models[currentImage]);

А теперь такой момент - для какой-то части этих мешей (например, для пятидесяти мешей) мне юниформы обновлять не надо, и можно сделать так:

  
dynamicAlignment_Model = 1024;
for (int ni = 0; ni < 50; ni++) {  
    int n = p->ff->modelsIndexes[ni];

    void* data;
    vkMapMemory(logicalDevice, uniformBuffersMemory_Models[currentImage], p->ff->models[n].n * dynamicAlignment_Model, VK_WHOLE_SIZE, 0, &data);

    glm::mat4* modelPtr = (glm::mat4*)(((uint64_t)modelUBO.model + (n * dynamicAlignment_Model)));
    memcpy(data, modelPtr, dynamicAlignment_Model);
    vkUnmapMemory(logicalDevice, uniformBuffersMemory_Models[currentImage]);
}

Собственно, вопрос, какой из вариантов в обобщенном случае быстрее - обновить огромный блок памяти 100*1024 за один раз, или обновить в два раза меньшее количество памяти, но сделать это в цикле 50 раз по 1024?

Полагаю, что за один раз (первый вариант, без цикла) будет побыстрее в данном случае, я прав или позор мне?

#8351
7:07, 31 мар. 2021

MikeNew
делаю ставку шо первый кейс быстрее

#8352
7:30, 31 мар. 2021

MikeNew
если один из вариантов точно не имеет дополнительной цены, а второй может иметь, то сам-то как думаешь, какой из них лучше?

#8353
7:41, 31 мар. 2021

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

#8354
7:47, 31 мар. 2021

MikeNew
> Вопрос в том как из этих цен дороже.
тестил  ?

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