Войти
ФлеймФорумПроЭкты

FrameGraph (3 стр)

Страницы: 1 2 3 4 59 Следующая »
#30
23:46, 20 дек. 2018

0r@ngE
> Это NIH синдром, это нормально.
Не в этом случае.
Там вроде бы нет поддержки нескольких девайсов. Нет атрибута [[nodiscard]] и весьма неудобно когда у тебя хэдеры одной версии, а лоадер другой.

#31
23:58, 20 дек. 2018

/A\
> Там вроде бы нет поддержки нескольких девайсов.

void volkLoadInstance(VkInstance instance);
void volkLoadDevice(VkDevice device);

а так же:
> For applications that use multiple VkDevice objects, load device-related Vulkan entrypoints into a table:

void volkLoadDeviceTable(struct VolkDeviceTable* table, VkDevice device);

Но я нисколько не агитирую, если что.

#32
0:11, 21 дек. 2018

0r@ngE
Но девасовые функции все равно видимы глобально, нет защиты от того что ты обратишься к ним, а там может быть либо нулевой указатель, либо указатель на функции другого девайса.

#33
6:24, 21 дек. 2018

/A\
> Но девасовые функции все равно видимы глобально
я же показал для этого выше volkLoadDeviceTable, функции сидят потом в таблице, для каждого девайса своя таблица, потом вместо

vkDoSomethingCool();
пишешь
table->vkDoSomethingCool();
#34
12:50, 21 дек. 2018

0r@ngE
Ну вот пишешь
dev1->vkDoSomethingCool();
dev2->vkDoSomethingCool();
а в другом месте забыл и написал
vkDoSomethingCool()
и оно скомпилится, а потом упадет.

#35
17:46, 21 дек. 2018

/A\
А еще можно выйти за пределы массива, обратиться к нулевому указателю, забыть обнулить удаленную память и т.д.  Куча способов написать плохой код.

Я тебе ответил на
> вроде бы нет поддержки нескольких девайсов

и все, не нравится - не юзай. Не зачем мне доказывать что в теории, при кривых руках, все может упасть.

#36
19:41, 23 дек. 2018

Отправная точка получена - 9 фпс на трейсе дума. На обычном трейсе 100фпс, а вообще в думе должно быть около 200фпс.

+ Показать

#37
2:40, 24 дек. 2018

/A\
прикольно

#38
3:08, 24 дек. 2018

Suslik
На самом деле не очень прикольно, у меня 50% времени цпу уходит на размещение барьеров и 70% времени гпу на обновление буферов. Без этого легко было бы 100фпс и более.
Но пока делал не мало ошибок пофиксил.

#39
(Правка: 3:17) 3:11, 24 дек. 2018

/A\
какие имено буферы так долго обновляются?  как твоё обновление буферов на стороне гпу отличается от их?

что именно включено в трейс и за чем тебе нужно следить самому?

#40
3:39, 24 дек. 2018

Suslik
Я конвертирую vktrace в вызовы моего фреймграфа, поэтому всю работу делает он.
Проблема с обновлением буферов в том, что я точно не знаю какие данные находятся на гпу, я могу только узнать что записано в staging buffer перед рисованием кадра, видимо где-то тут ошибка и получается слишком много обновлений, там несколько тысяч вызовов на кадр.
С барьерами чуть сложнее, там надо делать все ресурсы readonly и только те, что меняются захватывать для изменения. Это было в планах уже давно, но раньше не было заметно просадки производительности.

#41
20:06, 24 дек. 2018

Оказалось в дум юниформ буфер был host visible, а я при конвертации сделал заливку данных в device local память и на этом получил до 9к вызовов апи и жуткую загрузку цп при расстановке барьеров.
Еще сделал что если у бефера в usage нет TransferDst или Storage значит он ридонли и барьеры для него не нужны. Для image такое сработает только если будет 1 лейаут, но пока вообще не кретично.
В итоге я получил 30-40 фпс.
40% времени цпу уходит на memcpy, 20% на фреймграф, остальное на present и чтение трейса.
Пока сойдет, пойду чем-то более веселым займусь, например рейтерсом)

#42
8:00, 30 дек. 2018

вот здесь: https://gpuopen.com/presentation-porting-engine-to-vulkan-dx12/
рекомендуют frame graph делать зависимости не через какой тас зависит от какого, а какой таск использует какие ресурсы. например, если какой-то таск принимает ресурс A, а выдаёт B и C, то таски, использующие эти ресурсы, могут стартовать, как только он закончится. ресурсы — рендертаргеты, например.

#43
12:31, 30 дек. 2018

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

Кстати, в CUDA добавили графы https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#cuda-graphs

#44
(Правка: 20:36) 20:34, 10 янв. 2019

Добавил дебаггер шейдеров в фреймграф, раньше было отдельной демкой, теперь доработал.
Пока поддерживаются пиксельный и компьют шейдеры, не поддерживаются структуры и матрицы, но постепенно все добавлю.
пример

Пишем такой шейдер:

uint  index  = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;
uint  size  = gl_NumWorkGroups.x * gl_NumWorkGroups.y * gl_WorkGroupSize.x * gl_WorkGroupSize.y;
float  value  = sin( float(index) / size );
imageStore( un_OutImage, ivec2(gl_GlobalInvocationID.xy), vec4(value) );
получаем такой трейс
// gl_GlobalInvocationID: uint3 {8, 8, 0}
no source

// index: uint {136}
// gl_GlobalInvocationID: uint3 {8, 8, 0}
10. index  = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;

// size: uint {256}
11. size  = gl_NumWorkGroups.x * gl_NumWorkGroups.y * gl_WorkGroupSize.x * gl_WorkGroupSize.y;

// value: float {0.506611}
// index: uint {136}
// size: uint {256}
12. value  = sin( float(index) / size );

Страницы: 1 2 3 4 59 Следующая »
ФлеймФорумПроЭкты