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

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

Страницы: 1377 378 379 380405 Следующая »
#5655
9:49, 12 сен. 2019

Детские вопросы про Vulkan:

1) При использовании Вулкана для рендера одной и той же несложной сцены производительность и/или энергоэффективность будет выше, чем в OpenGL, или такой же?
2) Вулкан обязан поддерживаться операционной системой или это "почти обёртка над OpenGL"? Другими словами, если я хочу поддерживать старое железо, мне надо будет писать две реализации, и Vulkan, и OpenGL, так?
3) Есть ли какие-то причины начать использовать Вулкан при условии, что я не ставлю задачу рендерить фотореалистичную графику и мне хватает функционала OpenGL 2.1?


#5656
9:52, 12 сен. 2019

romanshuvalov
> 1) При использовании Вулкана для рендера одной и той же несложной сцены
> производительность и/или энергоэффективность будет выше, чем в OpenGL, или
> такой же?
при правильном использовании — не ниже. на практике есть все шансы сделать медленнее.

> 2) Вулкан обязан поддерживаться операционной системой или это "почти обёртка над OpenGL"? Другими словами, если я хочу поддерживать старое железо, мне надо будет писать две реализации, и Vulkan, и OpenGL, так?
поддерживаться не обязан, но поддержка достаточно широкая. включая всякие мобилы, макоси(через moltenvk) и линупсы.

> Есть ли какие-то причины начать использовать Вулкан при условии, что я не ставлю задачу рендерить фотореалистичную графику и мне хватает функционала OpenGL 2.1?
если ты не чувствуешь необходимости, то нет.

#5657
10:01, 12 сен. 2019

BingoBongo
>Флаг >VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_>ONLY_OPTIMAL несовместим с флагом >VK_IMAGE_USAGE_STORAGE_BIT в image >usage. Validation layer молчал.
забей баг на ,Слои валидации сделай мир лучше, еще лучше сделай pull request, если сможешь сам поправить.

#5658
(Правка: 10:35) 10:32, 12 сен. 2019

Suslik
> при правильном использовании — не ниже. на практике есть все шансы сделать
> медленнее.
Тогда тот же вопрос про OpenGL 2.1 против 4.5. (У меня сейчас шейдеры #version 120 без указаний in/out и я не знаю, есть ли смысл переписывать на более новую версию если нет острой необходимости во всяких там инстансингах и проч.)

А заставила задуматься статья на хабре, правда про эппловский Metal, на котором производительность возросла чуть ли не вдважды (и/или снизилось энергопотребление, что важно для мобил). (https://m.habr.com/ru/company/mailru/blog/430850/)

#5659
(Правка: 10:43) 10:37, 12 сен. 2019
romanshuvalov

Так и пиши на Metal.
Он хорошо оптимизирован и легковесный.
Но для эплов.
В чем же плох метод, описанный выше? Он плох в том, что между GPU и API есть посредник — драйвер. И именно он управляет задержками. В API Metal же буферы команд открыты, и приложение может само их заполнять и отправлять их в очередь команд для выполнения на GPU. Таким образом, приложение имеет полный контроль над заданием и может управлять задержками. Более того — теперь можно легко параллелить команды и помещать их в буфер в определенном порядке, так как для программиста становится более очевидным то, какие результаты в каком порядке будут доступны.
И тут возникает вопрос — а про какое десятикратное увеличение производительности вела речь Apple? Да вот именно про то, что время вызова на CPU теперь сильно меньше. Но вот GPU тут почти не затрагивается, так что в итоге напрямую улучшить графику за счет API Metal увы — нельзя. Но так как освободился процессор — его можно загрузить физикой: обсчетом физики частиц
#5660
10:44, 12 сен. 2019

ronniko
Какой Метал, я пишу для пэка на липупсах с желанием поддержать наибольшее количество старых устройств. Но когда придет время портироваться на айос, не хочу, чтоб меня забанили в аппстор за злостное неиспользование Метала. Ищу универсальное решение, которое позволит не делать несколько версий и при этом не навредит.

#5661
10:45, 12 сен. 2019

romanshuvalov
На вулкане легче сделать быстрее, если знаешь вулкан, ибо opengl - это обертка над вулканом, а не наоборот со всеми вытекающими проблемами и преимуществами. Основное - на вулкане легче загрузить gpu на 100% без простоев, если речь идет об игре; если же речь идет о gpgpu, то производительность будет одинаковой, а вулкан только увеличит время разработки.

#5662
(Правка: 10:48) 10:47, 12 сен. 2019

Было:

struct  PushConstants_ShadowOmni {
  glm::mat4 depthMVP;
  int index;
};

layout(push_constant) uniform PushConsts {
  mat4 depthMVP;
  int index;
} pushConsts;

Работает и на Нвидии и на Радеоне.
Стало:

struct  PushConstants_ShadowOmni {
  alignas(0) int index;
  alignas(16) glm::mat4 depthMVP;
};

layout(std430, push_constant) uniform PushConsts {
  int index;
  mat4 depthMVP;
} pushConsts;

В итоге на Нвидии все работает, а на Радеоне вылетает с VK_ERROR_DEVICE_LOST.
Что такое с Радеоном?  Размер не превышен, выравнивание верное. Чего ему надо?

#5663
(Правка: 10:55) 10:53, 12 сен. 2019

Может лучше не alignas(0) int index;
А ivec2 index; mat4 depthMVP;

Или:

int index;
int index2;
mat4 depthMVP;

#5664
11:02, 12 сен. 2019

ronniko
> int index;
> int index2;
Тогда уж
А ivec4 index; или
int index;
int index2;
int index3;
int index4;

И все равно вылетает.
На Интелл не вылетает, но передается неправильно.

#5665
11:05, 12 сен. 2019

MikeNew
> int index;
> mat4 depthMVP;
например, можно начать с того, что расположить мемберы в размере по порядку убывания. во-вторых, использовать #pragma push(pack, 1) и вручную расставить padding до float4. в-третьих, через reflection как минимум всегда проверять финальный размер буфера, который загружаешь, с буфером, который ожидает шейдер.

#5666
(Правка: 12:15) 12:13, 12 сен. 2019

Suslik
> например, можно начать с того, что расположить мемберы в размере по порядку
> убывания. во-вторых, использовать #pragma push(pack, 1) и вручную расставить
> padding до float4. в-третьих, через reflection как минимум всегда проверять
> финальный размер буфера, который загружаешь, с буфером, который ожидает шейдер.

#pragma push (и не помогло оно) же не рекомендуют же использовать.

Помогло с Радеоном расположение по порядку убывания

  struct  PushConstants_ShadowOmni {
    glm::mat4 depthMVP;
    int index;
  };
и

layout(push_constant) uniform PushConsts {
  layout (offset = 0) mat4 depthMVP;
  layout (offset = 64) int index;
} pushConsts;

На Интеле матрица передается правильно, а index всегда равен нулю, с какого хрена - непонятно.

#5667
12:16, 12 сен. 2019

Suslik
> через reflection как минимум всегда проверять финальный размер буфера, который
> загружаешь, с буфером, который ожидает шейдер.
Первый раз про такое слышу, надо гуглить.

#5668
(Правка: 20:08) 20:06, 12 сен. 2019

Я лично одновременно закидываюсь `#pragma push(pack, 1)` и `VK_EXT_scalar_block_layout`, говорят помогает гарантированно...
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html… _block_layout
https://github.com/KhronosGroup/GLSL/blob/master/extensions/ext/G… ck_layout.txt

#5669
(Правка: 6:26) 6:26, 13 сен. 2019

Я разобрался - оказывается у меня с pipelineLayuot было напутано немножко - теперь работает на всех трех картах.
Но это не я виноват, это Нвидия виновата, что кривой код на ней нормально работает. Так что лучше разработку вести на Интел или Радеон, а то, похоже, Нвидия заботливо подставляет костыли таким как я. :)
Вспоминаются новости на манер "Игроки жалуются что игра не запускается на AMD Radeon".

Страницы: 1377 378 379 380405 Следующая »
ПрограммированиеФорумГрафика