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

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

Страницы: 1427 428 429 430488 Следующая »
#6405
22:11, 23 фев. 2020

Panzerschrek[CN]
> uniform sampler2D tex[4];
> in vec3 tex_coord;
> out vec4 color;
> void main()
> {
> int tex_number= int(tex_coord.z);
> if(tex_number == 0)
> color= texture(tex[0], tex_coord.xy);
> else if(tex_number == 1)
> color= texture(tex[1], tex_coord.xy);
> else if(tex_number == 2)
> color= texture(tex[2], tex_coord.xy);
> else if(tex_number == 3)
> color= texture(tex[3], tex_coord.xy);
> }
У тебя будет четыре текстурные выборки в шейдере, потом cmp.


#6406
22:35, 23 фев. 2020

v1c
> У тебя будет четыре текстурные выборки в шейдере, потом cmp.
Уверен?
Что-то мне подсказывает, что на современном железе это не так. Я уже гоняю во фрагментом шейдере циклы с заранее неизвестным количеством итераций. Погонять ещё условий - будет не страшно. Тем более, у меня номер текстуры редко меняется в пределах треугольника.

#6407
(Правка: 22:56) 22:54, 23 фев. 2020

Кстати, по поводу бранчей, нашел такой комент и забыл сюда запостить)

Branches are only an issue if your local threads(wavefront/warp) take different paths. If all threads within a warp take the same path, there is no cost besides the evaluation of the conditional itself.  Since threads in a warp share the same instruction counter, ff threads don't all take the same path, they will be split into separate warps halving the occupancy, the more nested branches like this there are the worse your occupancy can get.  Some "branches" can be compiled to single instructions or non branching operations, especially small arithmetic symmetric branches, but if you are conditionally reading from memory in one branch and adding to a value in another, this is unlikely to happen.  You can also ignore this problem often if *most* of the time one branch is taken. Under those scenarios, even if a few warps experience divergence, most won't, so your occupancy will still be around 90+%.

https://www.shadertoy.com/view/tdXGWr

Только из этого следует, что static / dynamic branching уже не имеет смысла, раз dynamic branching работает.
Еще давно видел презентацию АМД, где показывали как бранчи выполняются в варпах, там немного иначе было, чем здесь объясняется.

#6408
13:55, 24 фев. 2020

Panzerschrek[CN]
> Что-то мне подсказывает, что на современном железе это не так.
Выборки из памяти не бранчятся, если текстурные координаты известны заранее, железо может фетчить заблаговременно.

#6409
19:49, 24 фев. 2020

/A\
> Только из этого следует, что static / dynamic branching уже не имеет смысла,
> раз dynamic branching работает.
Во первых dynamic branching - это все еще инструкция в рантайме. Она же не совсем бесплатная. Во вторых - при статик бранчинге можно выкинуть все неиспользуемые регистры, и потребление памяти будет меньше. Потенциально это даст больший вейвфронт когда мы упираемся в регистровую память.

#6410
20:21, 24 фев. 2020

MrShoor
> то все еще инструкция в рантайме. Она же не совсем бесплатная
Думаю, стоимость инструкции условия намного ниже, чем стоимость выборки из текстуры. А значит, запихать выборку под if будет норм вариант, при условии, что у соседних потоков результат if будет одинаковым.

#6411
21:22, 24 фев. 2020

Panzerschrek[CN]
> А значит, запихать выборку под if будет норм вариант, при условии, что у
> соседних потоков результат if будет одинаковым.
Да. И на десктопном железе оно оставляет выборку под if-ом. Тут главное не забывать, что обычные выборки, типа Sample - неявно берут производные по UV через ddx,ddy/dFdx,dFdy. А вот эти производные в бранче брать нельзя. Поэтому компилятор под if-ом либо вынесет такую выборку наружу, либо откажется компилировать. Поэтому может сложиться впечатление, что выборки в бранчах нельзя, но на самом деле можно. Просто нужно взять производные вне цикла, а внутри использовать SampleGrad функции.

#6412
11:43, 7 мар. 2020

В новом Vulkan Header добавили расширение от Qualcomm, вышедшее в ноябре.

#6413
12:14, 7 мар. 2020

Andrey
это большой прогресс

#6414
7:36, 8 мар. 2020

Zeux накатал статью:

Writing an efficient Vulkan renderer
https://zeux.io/2020/02/27/writing-an-efficient-vulkan-renderer/

#6415
2:22, 10 мар. 2020

так всетаки, если вдруг тут мимо пробегали телепаты.

может кто-нибудь подсказать что за проблема у меня на встроенной intel видеокарте uhd 630

на сайте драйверов написано что поддерживается Vulkan 1.2 (драйвера 26.20.100.7755)

Но у меня почему-то все сторонние обертки (оказалось что не только bgfx, но и другие) падают при создании physical device
Instance, Validation, 0:  [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object: VK_NULL_HANDLE (Type = 1) | Missing extension required by the device extension VK_KHR_external_memory: VK_KHR_external_memory_capabilities. The Vulkan spec states: All required extensions for each extension in the VkDeviceCreateInfo::ppEnabledExtensionNames list must also be present in that list.


при этом просто примеры (например из SDK) работают, падают именно обертки (возможно инициализируют не как в туториале по вулкану). Так как обертки ковырять сложно, вулкан я еще не умею даже на уровне треугольника, то не могу как-то определить проблемное место

#6416
17:17, 14 мар. 2020
2020-03-14_133744 | Vulkan API (вышел!)
#6417
18:55, 14 мар. 2020

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

а вот АМД на убирание любого из семафоров сразу падает, без фенсов даже одна отрисовка окна не работает

#6418
19:23, 14 мар. 2020

Danilw
> и нвидия даже не напряглась все работает как надо

выйдет новый драйвер и сломается

#6419
20:13, 14 мар. 2020

оно работает и в драйвере линукса и виндовс, думаю это на низком уровне драйверов, что оно одинаково везде

Страницы: 1427 428 429 430488 Следующая »
ПрограммированиеФорумГрафика