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

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

Страницы: 1452 453 454 455586 Следующая »
#6780
(Правка: 8:26) 8:16, 1 мая 2020

/A\
> То есть драйвер выполняет все последовательно, если в нем нет ошибок, то предыдущему кадру просто неоткуда появиться.
мне кажется, это имеет смысл тестить до победного, чтобы хотя б в будущем знать, когда снова на эту проблему напарываешься. надо понять, что именно обозначает "показывается предыдущий кадр": означает ли это, что ты рендеришь новый кадр с uniform buffer'ом старого кадра по второму разу, ты present'ишь ранее отрендеренный кадр ещё раз (а текущий кадр, соответственно, навсегда теряется?), либо uniform buffer используется новый, а command buffer почему-то используется из предыдущего submit'а?

попробуй рендерить прямо на surface следующую информацию: номер image в свопчейне, номер image в frame-in-flight и глобальный номер кадра, записанный в uniform buffer, и глобальный номер кадра, инкрементируемый через atomic в шейдере. причём всю информацию нужно дублированно рендерить тремя способами параллельно: выводить в консоль + используя чисто фрагментный шейдер + кодируя цветом значения в uniform buffer'е и чисто геометрией (линиями шрифт, например, рисовать или просто количеством чёрточек на экране кодировать). потому что нужно понять, это чисто данные в buffer'е приходят старые, либо весь command buffer старый, либо оно present'ит не то, что ты рендеришь.

далее в идеале нужно записать покадрово видео, чтобы посмотреть, что именно обозначает этот "пропущенный" кадр. значит ли это, что один кадр, который ты отрендерил, навсегда теряется и вместо него показывается какой-то предыдущий? но что становится с атомиками, которые модифицируются в "пропущенном" кадре — действительно ли он даже не уходит на исполнение, или просто не present'ится? но, разумеется, при записи баг может не воспроизводиться. гетто-способ — можно просто телефоном с экрана писать высокочастотное видео с экранного профайлера, мы так иногда труднозаписываемые баги отлаживаем, лол.


#6781
10:15, 1 мая 2020

/A\
> У меня баг остается даже если я ставлю vkDeviceWaitIdle

делаю ставку на баг драйвера

#6782
11:16, 1 мая 2020

innuendo
> делаю ставку на баг драйвера
Я это уже 2 раза сказал)

Suslik
> мне кажется, это имеет смысл тестить до победного
Ну ладно, вот результаты:
1. На видео баг не проявляется. До презента color target копируется в staging buffer и потом добавляется кадр видео. Запись с экрана не пробовал.
2. При записи с камеры получил такую последовательность 2, 3, 4, 8, 6, 10, 8, 9, 10, 11...
present mode = VK_PRESENT_MODE_FIFO_KHR
Так что это баг в presentation engine.

#6783
(Правка: 11:37) 11:32, 1 мая 2020

/A\
> При записи с камеры получил такую последовательность 2, 3, 4, 8, 6, 10, 8, 9, 10, 11...
погоди, но это значит, что после рендеринга кадра 4 должен был образоваться lag spike в 3 кадра длиной, чтобы вообще узнать, что будет отрендерено в кадре 8. как именно ты передавал информацию о номере кадра: через uniform buffer, через vertex buffer или через разные дроколлы? согласуется ли вся эта информация? согласуется ли информация, если номер кадра считать через атомик в шейдере? потому что от этого принципиально зависит, что именно глючит: передача данных, порядок исполнения, либо порядок отображения.

я бы для начала как минимум запустил компьют шейдер с atomicAdd в один поток, чтобы номер кадра считать через него, чтобы исключить влияние uniform buffer'ов, fence'ов и host coherent синхронизаций.

> > делаю ставку на баг драйвера
> Я это уже 2 раза сказал)
даже если это баг драйвера (в этом всё ещё нельзя быть уверенным), гораздо выше шанс, что его пофиксят, если максимально разобраться, в чём он именно заключается. если просто отправить багрепорт "у вас presentation engine сломан", ясное дело, его никто читать будет.

#6784
12:48, 1 мая 2020

Suslik
Но ведь в видео баг не проявляется, значит в юниформ буфер все правильно передается.
Номер кадра я выводил через ImGui, а там в вершинный буфер записывается через staging buffer.

#6785
13:04, 1 мая 2020

/A\
> Но ведь в видео баг не проявляется, значит в юниформ буфер все правильно
> передается.
вообще не факт, потому что это может значит, что при записи видео тайминги сдвигаются и staging buffer читается нужном состоянии, а без записи ты успеваешь его чем-то перезаписать (или драйвер не успевает что-то где-то синхронизировать). у любой проблемы, зависящей от таймингов, практически никогда нельзя сказать, что "Х работает правильно", так как если проблема не воспроизводится, это лишь значит, что ты её не воспроизвёл.

> Номер кадра я выводил через ImGui, а там в вершинный буфер записывается через staging buffer.
я уже кучу раз говорил, но я бы вообще выкинул из уравнения весь device-host memory transfer и инкрементировал номер кадра прямо в шейдере. потому что в противном случае не исключено, что это каким-то образом именно staging buffer, которым пользуется imgui, каким-то образом не в тот момент доезжает до gpu.

#6786
13:38, 1 мая 2020

Suslik
> так как если проблема не воспроизводится, это лишь значит, что ты её не воспроизвёл.
Не, на экране воспроизводится, а на в тот же момент записаном видео - нет.

#6787
14:07, 1 мая 2020

ты не можешь доверять записанному видео(другой программой) потому что оно берется не с текущего кадра, и ОС решает какой кадр дать в текущий момент
только скриншотам со своей программы(сделанной внутри твоего кода имею в виду как сохранение картинки) можно доверять

П.С. еще вспомнил где видел такое лаг - при ВСинке который конфликтовал с ВСинком ОС, было на Нвидии в Линуксе, хотя теоретически возможно и на винде

#6788
11:45, 8 мая 2020

Если в шейдере указать 2 ресурса с одинаковым set и binding, то компилятор glslang это спокойно скомпилирует. Слои валидации тоже это не проверяют, да еще и пропускают обновление дескриптора по несуществующему индексу, а вот драйвер падает.
Я то думал такие очевидные ошибки уже отлавливают.

#6789
15:15, 8 мая 2020

/A\
> а вот драйвер падает.
что именно падает
драйвер после компиляции SPIR-V в бинарник?
или компилятор SPIR-V в драйвере

единственная "эталонная система" по дебагу вулкана это открытый драйвер АМД в линуксе(amdgpu)
там и красивый LLVM который компилирует SPIR-V с ошибками, а не молча
и драйвер который отваливается с логами

если не лень дебаж там, только проблема в том что "то что там работает" может не заработать проприетарных драйверах Нвидии и АМД, и наоборот(багов в amdgpu тоже полно и с каждым обновлением отваливается какаято игра на вулкане из стима)

больше всего костылей и подпорок под вулканом сделали в двух проектах что я знаю
открытый DXVK(и dx9vk) там специальные куски кода под АМД и Нвидию, эмуляция АМД на Нвидии и тому подобное
и CEMU но он закрыт (CEMU не имеет ошибок валидации но работает не на всех версиях драйверов, и далеко не на всех видеокартах(у меня на старой 750 Нвидии не работает и у многих, хотя все другое даже Дум там работает, но работает на более новой АМД))
CEMU интересен тем что компилирует по 6Гб+ шейдеров на игру и использует тыщи шейдеров на кадр, далеко не все видеокарты такое могут выдержать

#6790
18:16, 8 мая 2020

Danilw
> что именно падает
Падает при записи дескриптора по несуществующему индексу, только поэтому я и обнаружил что у меня 2 одинаковых индекса в шейдере.

#6791
(Правка: 22:46) 22:46, 8 мая 2020

чем можно записать окно приложения на вулкане? я amd relive пользовался, но эти ушлепки выкосили его из новых драйверов.

#6792
22:52, 8 мая 2020

BingoBongo
Из новых - это из каких? Вроде бы всё на месте, они там только улучшали что-то.

#6793
23:07, 8 мая 2020

gkv311
не помню, какая у меня была версия - где-то месячной давности, но я сейчас новую накатил.

вот мое текущее окно настроек

+ Показать

а вот как было

+ Показать

#6794
(Правка: 23:23) 23:21, 8 мая 2020

Это закладка для стримнига видео во всякие твитчеры.
Кнопка записи рабочего стола на первой вкладке, а настройки разбросаны в глубине.

+ Показать

Страницы: 1452 453 454 455586 Следующая »
ПрограммированиеФорумГрафика