Вулкан, почему слои проверки (и, как следствие, spe c) запрещают конвейерам не писать в определенные вложения? - PullRequest
Новая
       71

Вулкан, почему слои проверки (и, как следствие, spe c) запрещают конвейерам не писать в определенные вложения?

0 голосов
/ 22 февраля 2020

В vulkan, если за время жизни одного прохода рендеринга вы наивно визуализируете в фрейм-буфер, который содержит несколько Attachemnts с конвейером, который рендерится всем им, а затем снова рендеринг с конвейером, который рендерит только одному из них, вы будете получить ошибку.

Позвольте мне привести пример.

Рассмотрим следующее изображение, которое является промежуточным шагом в многопроходном эффекте. enter image description here

Что получается при написании каркаса поверх альбедо: 

#version 450
#extension GL_ARB_separate_shader_objects : enable

layout(location = 0) out vec4 color_out;
layout(location = 1) out vec4 color_out1;
layout(location = 2) out vec4 color_out2;
layout(location = 3) out vec4 color_out3;
layout(location = 4) out vec4 color_out4;

void main()
{
    color_out = vec4(1,1,1,1);
    color_out1 = vec4(0,0,0,0);
    color_out2 = vec4(0,0,0,0);
    color_out3 = vec4(0,0,0,0);
    color_out4 = vec4(0,0,0,0);
}

4 выхода "n oop" на самом деле не нужны они существуют просто для предотвращения ошибок вулканов.

Давайте предположим, что мы вместо этого делаем это (и мы также модифицируем наш пиелин): 

#version 450
#extension GL_ARB_separate_shader_objects : enable

layout(location = 0) out vec4 color_out;

void main()
{
    color_out = vec4(1,1,1,1);
}

Затем мы получаем то же изображение.

enter image description here

Однако существует критическая разница:

Второе изображение выдает несколько ошибок, по одной на каждого атташе, которые выглядят так: 

Message ID name: UNASSIGNED-CoreValidation-Shader-InputNotProduced
Message: Attachment 1 not written by fragment shader; undefined values will be written to attachment
Severity: VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT

Почему запись явно во вложения кадрового буфера недействительна согласно спецификации c? то есть, почему spe c не означает, что если вы не пишете вложение, содержимое сохраняется?

1 Ответ

1 голос
/ 23 февраля 2020

почему специфика c не означает, что если вы не пишете вложение, содержимое сохраняется?

Поскольку Vulkan - это низкоуровневый API рендеринга.

То, что записывается, всегда, в OpenGL, как и в Vulkan, регулировалось состоянием маска записи , а не тем, что делает фрагментный шейдер. Если у вас есть некоторое количество вложений, опять же в OpenGL, а также в Vulkan, любая операция рендеринга запишет во все из них (при условии, что пройдены различные тесты), если только маски записи (или смешивание) не используются для предотвращения этих записей.

Обратите внимание, что это различие вполне может быть аппаратной проблемой. Если графический процессор использует специализированное аппаратное обеспечение для интерпретации данных фрагмента и выполнения маскирования / записи / et c, вряд ли разумно считать, что у шейдера не может быть механизма прямой передачи того, какие значения во фрагменте являются действительными, а какие - нет. не.

Похоже, кажется, что некоторые аппаратные средства справляются с этим так, как вы бы предпочли . Или, по крайней мере, в некоторых случаях. Однако, поскольку мы рассматриваем неопределенное поведение, нет способа узнать, что его вызывает или в каких случаях оно может не функционировать.

Теперь можно сказать, что, учитывая, что объект конвейера Vulkan включает в себя все В этом состоянии код, который строит данные о состоянии внутреннего конвейера, может просто определять, какие значения записываются FS, и маскировать запись из остальных. Но это как бы против низкоуровневого API.

...