Vulkan API (вышел!) (218 стр) / Графика / Форум / Программирование игр / GameDev.ru

Dronas
> Мужчины R9 290 дружит с вулканкой?
в общем и целом всё начиная с 7870 дружит, но насколько полностью вопрос сложный, апи низкоуровневое и там нет гарантии 100% поддержки функционала вообще.

innuendo
Постоялец

#3257
10:36, 22 сен 2016

laMer007
> Так что ещё вопрос что более мертво

Причём заметь, тот, кто больше всех кричит о смерти GL, не торопится переводить свой супер-пупер движок на сабж...

The Player
Участник

#3258
0:03, 27 сен 2016

Кажется дефолтный переводчик GLSL -> SPIR-V неслабо так барахлит.
Шейдеры грузятся и работают, вот только совсем криво. Методом тыка было установлено, что в некоторых случаях переменная записывается значением соседней инструкции, которую убрал оптимизатор (другого объяснения пока нет).
Кто-нибудь с подобным встречался?

The Player
Участник

#3259
18:23, 27 сен 2016

SDC
Постоялец

#3260
18:38, 27 сен 2016

The Player
Попробуй с разными версиями.
Ну и выложи пример сюда на посмотреть.

GaHHuKoB
Пользователь

#3261
22:11, 18 окт 2016

Наткнулся на перевод буржуйских статей, мб кого заинтересует, вродь сделано не плохо. http://vulkanapi.ru/

innuendo
Постоялец

#3262
9:02, 20 окт 2016

http://gpuopen.com/vulkan-barriers-explained/

The Player
Участник

#3263
(Правка: 15:49) 15:39, 23 окт 2016

После небольшой передышки таки вернулся к Vulkan и проблеме преобразования шейдеров. Суть такова...
Есть обычная связка шейдеров (вершинный + фрагментный), которая, пока что, должна просто выводить текстурные координаты, но само собой выводит дерьмо:

+ vertex

− Скрыть

#version 450


struct ModelStruct
{
  mat4  modelViewProjectionMatrix;
  mat4  modelMatrix;
  mat3  rotateMatrix;
};


layout(set = 0, binding = 0, column_major) uniform ModelData
{
  ModelStruct modelData;
};


layout(location = 0)  in  vec3 vPos;
layout(location = 1)  in  vec3 vTan;
layout(location = 2)  in  vec3 vBin;
layout(location = 3)  in  vec3 vNor;
layout(location = 4)  in  vec2 vTex;


out  vec3    fPos;
out  mat3    fTBN;
out  vec2    fTex;


void main()
{
  fPos = (modelData.modelMatrix * vec4(vPos, 1.0f)).xyz;
  fTBN = modelData.rotateMatrix * mat3(vTan, vBin, vNor);
  fTex = vTex;


  gl_Position = modelData.modelViewProjectionMatrix * vec4(vPos, 1.0f);
  gl_Position.y = -gl_Position.y;
}

− Скрыть

#version 450


layout(set = 0, binding = 1)  uniform  sampler2D  textureColor;
layout(set = 0, binding = 2)  uniform  sampler2D  textureNormals;
layout(set = 0, binding = 3)  uniform  sampler2D  textureSpecular;


in  vec3    fPos;
in  mat3    fTBN;
in  vec2    fTex;


layout(location = 0)  out  vec4  oColor;


void main()
{
  oColor = vec4(fTex, 0.0f, 1.0f);
}

Обратите внимание на то, что ни fPos ни fTBN во фрагментном шейдере не используются, хотя мы их все таки передаем. Т.е., чисто теоретически, лунарский транслятор GLSL->SPIR-V или компилятор самого SPIR-V на видяхе все это дело оптимизируют.
Фокус в том, что если попросту убрать запись атрибутов fPos/fTBN в вершинном шейдере, то картина меняется на, кто бы мог подумать, правильную:

+ vertex

− Скрыть

#version 450


struct ModelStruct
{
  mat4  modelViewProjectionMatrix;
  mat4  modelMatrix;
  mat3  rotateMatrix;
};


layout(set = 0, binding = 0, column_major) uniform ModelData
{
  ModelStruct modelData;
};


layout(location = 0)  in  vec3 vPos;
layout(location = 1)  in  vec3 vTan;
layout(location = 2)  in  vec3 vBin;
layout(location = 3)  in  vec3 vNor;
layout(location = 4)  in  vec2 vTex;


out  vec3    fPos;
out  mat3    fTBN;
out  vec2    fTex;


void main()
{
  // fPos = (modelData.modelMatrix * vec4(vPos, 1.0f)).xyz;
  // fTBN = modelData.rotateMatrix * mat3(vTan, vBin, vNor);
  fTex = vTex;


  gl_Position = modelData.modelViewProjectionMatrix * vec4(vPos, 1.0f);
  gl_Position.y = -gl_Position.y;
}

− Скрыть

#version 450


layout(set = 0, binding = 1)  uniform  sampler2D  textureColor;
layout(set = 0, binding = 2)  uniform  sampler2D  textureNormals;
layout(set = 0, binding = 3)  uniform  sampler2D  textureSpecular;


in  vec3    fPos;
in  mat3    fTBN;
in  vec2    fTex;


layout(location = 0)  out  vec4  oColor;


void main()
{
  oColor = vec4(fTex, 0.0f, 1.0f);
}

И знаете что тут самое подозрительное? Первый (кривой) вывод один в один сходится со значением атрибута fPos, который, само собой, был оптимизирован.
Такое ощущение что оптимизатор до боли кривой и либо пишет не туда, либо читает не из того места.

~~Сейчас ставлю свежую 1.0.30.0 и буду проверять, осталась ли проблема...~~ Таки да, осталась.
Тем не менее, кто-нибудь с чем-нибудь подобным сталкивался?

SDC
Постоялец

#3264
16:32, 23 окт 2016

The Player
layout(location) для in/out нужно указывать. Они связываются не по именам, а по location.

gammaker
Постоялец

#3265
16:38, 23 окт 2016

The Player
А в Vulkan'е никакие биндинги\локации для вариингов явно указывать не нужно?

Правка: опередили

The Player
Участник

#3266
18:10, 23 окт 2016

SDC
gammaker
Спасибо! Пока что, вроде бы, помогло.
З.Ы. Впервые слышу о layout(location) для внутренних атрибутов.

JustForFun
Постоялец

#3267
19:30, 23 окт 2016

А может кто нибудь подсказать псевдокодом, как в вулкане сделать следующее.
Есть 1 юниформ буфер для матриц.

Обновить данные юниформ.
Вывести один объект (пусть будет куб).
Обновить данные юниформ.
Вывести другой объект (пусть будет сфера).

SDC
Постоялец

#3268
(Правка: 20:10) 19:48, 23 окт 2016

JustForFun
Завести 2 descriptor set`a и биндить для каждого объекта свой.

UPD:
-обновить буфер с per-object данными для всех объектов
-bind ds_for_cube
-draw cube
-bind ds_for_sphere
-draw sphere

The Player
Участник

#3269
19:53, 23 окт 2016

JustForFun
А в чем проблема?
Обновляешь буферы, отправляешь команды, ждешь выполнения.