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

/A\
> я же в самом начале говорил, что лейаут должен быть depth_read_only, тогда
> можно делать и тест глубины и читать из шейдера
Ах ты ж блин...
Моя невнимательность определенно когда-нибудь убьет меня.
Огромное тебе спасибо, теперь все работает.
И лишний проход не понадобился, прекрасно же! Таким решением я удовлетворен целиком и полностью.

MikeNew
Постоялец

#6003
(Правка: 10:31) 10:31, 2 дек. 2019

innuendo
> full screen quad - забей на вулкан пока не будешь знать техники
Ты предлагаешь учится на устаревшем апи. Не лучше ли одновременно учить теорию и работать с новым? Потом переучиваться не придется.
С вулканом у меня же движется, хоть и со скрипом.

Suslik
Модератор

#6004
(Правка: 11:05) 11:03, 2 дек. 2019

MikeNew
> Ты предлагаешь учится на устаревшем апи. Не лучше ли одновременно учить теорию
> и работать с новым? Потом переучиваться не придется.
> С вулканом у меня же движется, хоть и со скрипом.
мне кажется, учиться с конца вулкану (взять "работающий" пример с шедоумеппингом и допиливать его) — это очень плохая затея. примеры показывают, как пользоваться API и ни один из них не показывает, как вокруг него строить рендер. так можно поступать со всякими ~~ущербными~~ ~~старыми~~ легаси GAPI, которыми вообще при желании можно было без фреймворка пользоваться и просто лепить рендер сразу вокруг них. vulkan'ом без фреймворка пользоваться вообще нельзя. после того, как создан контекст вулкана и первый треугольник, надо не за более навороченный пример браться, а посмотреть на него и понять, почему этот подход не масштабируется. дальше нужно читать, что уже придумали люди в этом направлении, хотя бы http://themaister.net/blog/2017/08/15/render-graphs-and-vulkan-a-deep-dive/ или от фростбайта пейперы, долго читать http://themaister.net/blog/2019/08/14/yet-another-blog-explaining… chronization/ до тех пор, пока не сложится план, как написать код, который позволит полностью избежать подобных ошибок в будущем. это не ты должен копаться, что там подключено и какой там барьер поставлен, а автоматизированная система, которую ты написал ранее специально, чтобы таких ошибок не могло возникнуть. ты сейчас пытаешься ковшом от экскаватора вручную себе яму для компоста выкопать.

MikeNew
Постоялец

#6005
11:32, 2 дек. 2019

Suslik
> мне кажется, учиться с конца вулкану (взять "работающий" пример с
> шедоумеппингом и допиливать его)
Ну я так не извращался, я сначала долго вникал в Vulkan Tutorial.
Другое дело что там только самые основы.

innuendo
Постоялец

#6006
11:39, 2 дек. 2019

Suslik
> так можно поступать со всякими ущербными старыми легаси GAPI, которыми вообще
> при желании можно было без фреймворка пользоваться и просто лепить рендер сразу
> вокруг них. vulkan'ом без фреймворка пользоваться вообще нельзя

о как, возьму на заметку

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

/A\
Участник

#6007
11:40, 2 дек. 2019

Suslik
Рендер граф нужен если хочешь не напрягаясь использовать вулкан, но его писать долго.
Расставлять барьеры вручную не так уж плохо, но мне вот быстро надоело об этом задумываться)

А твой рендер граф умеет переводить лейаут в depth_read_only если нет теста глубины? Я такой случай начал поддерживать только когда запустил трейс дума и он упал из-за неправильного лейаута))

innuendo
Постоялец

#6008
12:16, 2 дек. 2019

/A\
> Расставлять барьеры вручную не так уж плохо, но мне вот быстро надоело об этом
> задумываться)

ну можно ставить top->bottom барьеры :)

а твой сцене граф сам подбирает стейджи да ?

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

/A\
Участник

#6009
12:46, 2 дек. 2019

innuendo
> а твой сцене граф сам подбирает стейджи да ?
конечно

Suslik
Модератор

#6010
(Правка: 13:30) 13:20, 2 дек. 2019

/A\
> А твой рендер граф умеет переводить лейаут в depth_read_only если нет теста
> глубины? Я такой случай начал поддерживать только когда запустил трейс дума и
> он упал из-за неправильного лейаута))

    core->GetRenderGraph()->AddPass(legit::RenderGraph::RenderPassDesc()
      .SetDepthAttachment(viewportResources->shadowMap.imageViewProxy->Id(), vk::AttachmentLoadOp::eClear) //вот тут при желании можно указать readonly, но я не заморачивался
      .SetRenderAreaExtent(shadowMapExtent)
      .SetProfilerInfo(legit::Colors::amethyst, "ShadowPass")
      .SetRecordFunc([this, passData](legit::RenderGraph::RenderPassContext passContext)
    {
    });

вообще в основе моего фреймграфа для расстановки барьеров изображений лежит такая структура, которую легко расширять для любого нового юзкейса:

  enum struct QueueFamilyTypes
  {
    Graphics,
    Transfer,
    Compute,
    Present,
    Undefined
  };
  struct ImageAccessPattern
  {
    vk::PipelineStageFlags stage;
    vk::AccessFlags accessMask;
    vk::ImageLayout layout;
    QueueFamilyTypes queueFamilyType;
  };
  struct ImageSubresourceBarrier
  {
    ImageAccessPattern accessPattern;
    ImageAccessPattern dstAccessPattern;
  };

  enum struct ImageUsageTypes
  {
    GraphicsShaderRead,
    GraphicsShaderReadWrite,
    ComputeShaderRead,
    ComputeShaderReadWrite,
    TransferDst,
    TransferSrc,
    ColorAttachment,
    DepthAttachment,
    Present,
    None,
    Unknown //means it can be anything
  };

  ImageAccessPattern GetSrcImageAccessPattern(ImageUsageTypes usageType)
  {
    ImageAccessPattern accessPattern;
    switch (usageType)
    {
      case ImageUsageTypes::GraphicsShaderRead:
      {
        accessPattern.stage = vk::PipelineStageFlagBits::eVertexShader;
        accessPattern.accessMask = vk::AccessFlags();
        accessPattern.layout = vk::ImageLayout::eShaderReadOnlyOptimal;
        accessPattern.queueFamilyType = QueueFamilyTypes::Graphics;
      }break;
      ...
    }
    return accessPattern;
  }
  ImageAccessPattern GetDstImageAccessPattern(ImageUsageTypes usageType)
  {
    ImageAccessPattern accessPattern;
    switch (usageType)
    {
      case ImageUsageTypes::GraphicsShaderRead:
      {
        accessPattern.stage = vk::PipelineStageFlagBits::eVertexShader;
        accessPattern.accessMask = vk::AccessFlagBits::eShaderRead;
        accessPattern.layout = vk::ImageLayout::eShaderReadOnlyOptimal;
        accessPattern.queueFamilyType = QueueFamilyTypes::Graphics;
      }break;
      ...
    }
    return accessPattern;
  }

идея в том, что каждый image внутри каждого таска может использоваться одним из способов, перечисленных в ImageUsageTypes. зная предыдущий image usage type и текущий, по ним можно сгенерить полную информацию о барьере для этого изображения, который нужно поставить перед пассом.

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

/A\
Участник

#6011
13:25, 2 дек. 2019

Suslik
> вот тут при желании можно указать readonly, но я не заморачивался
А я еще больше заморочился и если у всех дроуколов пасса нет записи в глубину, то ставится ридонли

Suslik
Модератор

#6012
13:27, 2 дек. 2019

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