FrameGraph (5 стр) / ПроЭкты / Форум / Флейм

/A\
> Чем раньше ты отправишь команды на гпу, тем раньше начнется рисование и это
> уменьшит задерку между инпутом и выводом на экран.
да, это действительно так. однако, наш текущий рендер построен именно вокруг константной задержки в 1 кадр — пока предыдущий кадр рендерится, текущий записывается. но, вообще говоря, мне ничто не мешает добавить таск вроде AddSubmit(), который бы сабмитил буфер посреди кадра.

/A\
> Так понятней. А что с зависимостями между ресурсами?
я там комментарий добавил после кода. вот аргументы AddRenderPass():

  frameInfo.renderGraph->AddRenderPass(
    { frameInfo.swapchainImageViewProxy }, //массив color attachment'ов. для обычных рендерпассов они вместе с буфером глубины являются массивом ресурсов на запись
     //граф анализирует следующее использование каждого рендертаргета и пытается перевести его в тот лейаут, в котором он понадобится в будущем
     nullptr, //буфер глубины
    {}, //массив ресурсов на чтение. если к началу исполнения таска ресурс находится не в том layout'е, то он автоматически переводится в eShaderRead барьером.
     inFlightQueue->GetImageSize(), //размер вьюпорта
    [&](legit::RenderGraph::RenderPassContext passContext) //функция записи пасса

/A\
> Это хорошо работает в одном потоке, проблема начинается когда другой поток
> параллельно записывает конец кадра и должен узнать, что можно переиспользовать
> эти рендертаргеты с начала кадра.
как я уже говорил, пассов в кадре мало (десятки) и их инициализацию нет смысла параллелить. параллелить имеет смысл запись дроколлов внутри каждого пасса.

$Андрей (/A\)$

/A\
Участник

#61
13:07, 16 фев. 2019

Suslik
> {}, //массив ресурсов на чтение.
А если забыл добавить? Там же куча текстур у объектов.

> наш текущий рендер построен именно вокруг константной задержки в 1 кадр — пока предыдущий кадр рендерится
Ну так и должно быть, просто заменяешь кадр на батч и выделяешь для каждого батча свой диапазон памяти из staging и const буферов.

> параллелить имеет смысл запись дроколлов внутри каждого пасса.
Обновление дескрипторов тоже, в вольфенштейне например на vkUpdateDescriptors и vkCmdBindDescriptors уходит 1-2мс на цпу за кадр.

Suslik
Модератор

#62
13:24, 16 фев. 2019

/A\
> А если забыл добавить? Там же куча текстур у объектов.
текстуры нужно добавлять только те, для которых нужна синхронизация. то есть шедоумепы, рефлекшен пробы и тому подобные. обычные текстуры объектов синхронизировать надо только если они, например, в этом же кадре загружаются через рендреграф. если синхронизация не требуется, их добавлять в список не надо.

/A\
> Обновление дескрипторов тоже, в вольфенштейне например на vkUpdateDescriptors и
> vkCmdBindDescriptors уходит 1-2мс на цпу за кадр.
ничто не мешает сделать свой пул с шейдерными константами на каждый тред и пусть они их байндят параллельно.

раб вакуумной лампы
Постоялец

#63
13:20, 17 фев. 2019

Вот смотрю я на то что ты делаешь, /A\, и с ужасом благодарю судьбу что я больше подобным не занимаюсь.

$Андрей (/A\)$

/A\
Участник

#64
16:02, 17 фев. 2019

раб вакуумной лампы
Ты бросил движкописательство и пошел формошлепить?

Suslik
Модератор

#65
17:40, 17 фев. 2019

раб вакуумной лампы
> Вот смотрю я на то что ты делаешь, /A\, и с ужасом благодарю судьбу что я
> больше подобным не занимаюсь.
можно подумать, ты раньше занимался чем-то кроме шлёпанья языком

$Андрей (/A\)$

/A\
Участник

#66
18:42, 19 фев. 2019

Похоже на сглаженые тени от RTX ?

rtx-on | FrameGraph

$Андрей (/A\)$

/A\
Участник

#67
21:29, 19 фев. 2019

В 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 );

Ну вот как так то?

Suslik
Модератор

#68
2:50, 20 фев. 2019

/A\
> Похоже на сглаженые тени от RTX ?
да, выглядит неплохо. я тоже умею рендерить такие тени, но только в скринспейсе и от толстых окклюдеров.

}:+()___ [Smile]
Постоялец

#69
3:49, 20 фев. 2019

/A\
> Похоже на сглаженые тени от RTX ?
Выглядит как-то странно. Там, что-ли, второй источник света, который светит только на дальний конец тени?

Suslik
Модератор

#70
4:12, 20 фев. 2019

}:+()___ [Smile]
> Выглядит как-то странно. Там, что-ли, второй источник света, который светит
> только на дальний конец тени?
явно же видно, что источник света не один

$Андрей (/A\)$

/A\
Участник

#71
8:59, 20 фев. 2019

}:+()___ [Smile]
> Там, что-ли, второй источник света, который светит только на дальний конец тени?
Второй источник тоже есть, но тень специально так сделана. Там учитывается расстояние от объекта, который бросает тень и чем дальше, тем слабее тень.

Suslik
Модератор

#72
10:49, 20 фев. 2019

/A\
> Там учитывается расстояние от объекта, который бросает тень и чем дальше, тем
> слабее тень.
оу, ну тогда смаел, конечно, прав — это полная шняга.

$Андрей (/A\)$

/A\
Участник

#73
13:03, 20 фев. 2019

Suslik
> оу, ну тогда смаел, конечно, прав — это полная шняга.
Не совсем. Предметы, отбрасывающие тень, также немного перекрывают и рассеяное освещение, поэтому чем дальше от них тем светлее должна быть тень. Но вообще надо делать GI, а то тени хоть и без лесенок как в шедоумапах, но все равно не то.

Вот четкая тень
rtx-on-2 | FrameGraph

Suslik
Модератор

#74
(Правка: 13:10) 13:09, 20 фев. 2019

/A\
очевидно, чтобы не было черноты в тенях, нужен нормальный GI или хотя бы ambient. также видны артефакты в виде размноженного контура от конечного набора лучей — попробуй их выпускать со случайным отклонением.

> Предметы, отбрасывающие тень, также немного перекрывают и рассеяное освещение
это называется ambient occlusion и он входит в GI