/A\
> Чем раньше ты отправишь команды на гпу, тем раньше начнется рисование и это
> уменьшит задерку между инпутом и выводом на экран.
да, это действительно так. однако, наш текущий рендер построен именно вокруг константной задержки в 1 кадр — пока предыдущий кадр рендерится, текущий записывается. но, вообще говоря, мне ничто не мешает добавить таск вроде AddSubmit(), который бы сабмитил буфер посреди кадра.
/A\
> Так понятней. А что с зависимостями между ресурсами?
я там комментарий добавил после кода. вот аргументы AddRenderPass():
frameInfo.renderGraph->AddRenderPass({ frameInfo.swapchainImageViewProxy }, //массив color attachment'ов. для обычных рендерпассов они вместе с буфером глубины являются массивом ресурсов на запись //граф анализирует следующее использование каждого рендертаргета и пытается перевести его в тот лейаут, в котором он понадобится в будущем nullptr, //буфер глубины {}, //массив ресурсов на чтение. если к началу исполнения таска ресурс находится не в том layout'е, то он автоматически переводится в eShaderRead барьером. inFlightQueue->GetImageSize( ), //размер вьюпорта [&]( legit::RenderGraph::RenderPassContext passContext) //функция записи пасса
/A\
> Это хорошо работает в одном потоке, проблема начинается когда другой поток
> параллельно записывает конец кадра и должен узнать, что можно переиспользовать
> эти рендертаргеты с начала кадра.
как я уже говорил, пассов в кадре мало (десятки) и их инициализацию нет смысла параллелить. параллелить имеет смысл запись дроколлов внутри каждого пасса.
Suslik
> {}, //массив ресурсов на чтение.
А если забыл добавить? Там же куча текстур у объектов.
> наш текущий рендер построен именно вокруг константной задержки в 1 кадр — пока предыдущий кадр рендерится
Ну так и должно быть, просто заменяешь кадр на батч и выделяешь для каждого батча свой диапазон памяти из staging и const буферов.
> параллелить имеет смысл запись дроколлов внутри каждого пасса.
Обновление дескрипторов тоже, в вольфенштейне например на vkUpdateDescriptors и vkCmdBindDescriptors уходит 1-2мс на цпу за кадр.
/A\
> А если забыл добавить? Там же куча текстур у объектов.
текстуры нужно добавлять только те, для которых нужна синхронизация. то есть шедоумепы, рефлекшен пробы и тому подобные. обычные текстуры объектов синхронизировать надо только если они, например, в этом же кадре загружаются через рендреграф. если синхронизация не требуется, их добавлять в список не надо.
/A\
> Обновление дескрипторов тоже, в вольфенштейне например на vkUpdateDescriptors и
> vkCmdBindDescriptors уходит 1-2мс на цпу за кадр.
ничто не мешает сделать свой пул с шейдерными константами на каждый тред и пусть они их байндят параллельно.
Вот смотрю я на то что ты делаешь, /A\, и с ужасом благодарю судьбу что я больше подобным не занимаюсь.
раб вакуумной лампы
Ты бросил движкописательство и пошел формошлепить?
раб вакуумной лампы
> Вот смотрю я на то что ты делаешь, /A\, и с ужасом благодарю судьбу что я
> больше подобным не занимаюсь.
можно подумать, ты раньше занимался чем-то кроме шлёпанья языком
Похоже на сглаженые тени от RTX ?
В closest hit shader пишем цвет (1,0,0)
//> (out): float3 {1.000000, 0.000000, 0.000000} // light: float3 {1.000000, 1.000000, 1.000000} 252. PrimaryRay.color = mtr.albedo * light;
В ray gen shader уже читаем (0,1,0)
//> color: float4 {0.000000, 1.000000, 0.000000, 1.000000} 120. color = vec4(PrimaryRay.color, 1.0f); //> imageStore(): void // gl_LaunchIDNV: uint3 {640, 480, 0} // color: float4 {0.000000, 1.000000, 0.000000, 1.000000} 122. imageStore( un_OutColor, ivec2( gl_LaunchIDNV), color );
Ну вот как так то?
/A\
> Похоже на сглаженые тени от RTX ?
да, выглядит неплохо. я тоже умею рендерить такие тени, но только в скринспейсе и от толстых окклюдеров.
/A\
> Похоже на сглаженые тени от RTX ?
Выглядит как-то странно. Там, что-ли, второй источник света, который светит только на дальний конец тени?
}:+()___ [Smile]
> Выглядит как-то странно. Там, что-ли, второй источник света, который светит
> только на дальний конец тени?
явно же видно, что источник света не один
}:+()___ [Smile]
> Там, что-ли, второй источник света, который светит только на дальний конец тени?
Второй источник тоже есть, но тень специально так сделана. Там учитывается расстояние от объекта, который бросает тень и чем дальше, тем слабее тень.
/A\
> Там учитывается расстояние от объекта, который бросает тень и чем дальше, тем
> слабее тень.
оу, ну тогда смаел, конечно, прав — это полная шняга.
Suslik
> оу, ну тогда смаел, конечно, прав — это полная шняга.
Не совсем. Предметы, отбрасывающие тень, также немного перекрывают и рассеяное освещение, поэтому чем дальше от них тем светлее должна быть тень. Но вообще надо делать GI, а то тени хоть и без лесенок как в шедоумапах, но все равно не то.
Вот четкая тень
/A\
очевидно, чтобы не было черноты в тенях, нужен нормальный GI или хотя бы ambient. также видны артефакты в виде размноженного контура от конечного набора лучей — попробуй их выпускать со случайным отклонением.
> Предметы, отбрасывающие тень, также немного перекрывают и рассеяное освещение
это называется ambient occlusion и он входит в GI
Тема в архиве.