Программный конвейерный шейдер обмена переменными - PullRequest
2 голосов
/ 20 января 2012

Мне нужно, чтобы vec4 и float передавались из вершинного шейдера в геометрический шейдер, а затем в фрагментный шейдер. 3 шейдера принадлежат 3 различным программам, чтобы поддерживать уникальность униформы, а 3 собираются в один программный конвейер с геометрическим шейдером, присоединяемым / отсоединяемым по мере необходимости.

Расширение GL_ARB_separate_shader_object говорит:

GLSL имеет модель «рандеву по имени» для соединения переменных выходных переменных с переменными входными переменными последующего шейдера. С отдельными шейдерами нет уверенности в том, что предыдущий шейдер запишет заданную пользователем переменную ввода. Программы расширения сборок HLSL9, Cg и OpenGL справляются с этой ситуацией с помощью модели «сближение с помощью ресурса API». В терминах GLSL это означает, что отдельные шейдеры GLSL / должны / должны взаимодействовать с помощью встроенных переменных, а не определяемых пользователем переменных.

хорошо, в вершинных и геометрических шейдерах я использовал gl_FrontColor для vec4 и gl_FogFragCoord для float, читая их во фрагменте через gl_FogFragCoord и gl_Color.

Работает, хорошо .. но .. я имею в виду .. cmon, правда?

Я могу понять причину всего этого, но это действительно кажется мне дурацким обходным путем. Неужели нет другого способа заставить разные шейдеры из разных программ общаться друг с другом, если они все работают в одном программном конвейере?

1 Ответ

4 голосов
/ 20 января 2012

Давайте сначала разберемся с этим: то, что вы читаете там, не соответствует этой функции расширения / ядра.Далее следует объяснение того, как это не соответствует действительности, если оно содержится в спецификации, и почему эта неправильная строка находится здесь в этой спецификации.

При чтении спецификаций расширения важно отметить разницу между следующим:

  • Нормативный текст: это определяет, как на самом деле работает расширение.Это основная часть текста.
  • Описательный текст: это дает необязательный обзор того, для чего предназначена функциональность.Он не является обязательным, то есть фактический нормативный текст может противоречить ему.
  • Метатекст: это объясняет причины, лежащие в основе нормативного текста.Он также представляет информацию верхнего и нижнего колонтитула (кто написал расширение, какие даты были опубликованы и т. Д.).

Описательный текст для расширений состоит из раздела «Обзор».1014 * Нормативный текст, часть, объясняющая, как все это работает, определяется разделами «Новые процедуры и функции», «Новые токены» и любым разделом формы «Дополнения / изменения в ... Спецификации».

Все остальное - метатекст.Но особенно раздел "Проблемы".В этом разделе объясняются некоторые причины решений, принятых в спецификации.То, что вы цитировали, взято из раздела «Проблемы».Он не является обязательным и, следовательно, не имеет отношения к реальной функциональности.

Теперь вы можете задаться вопросом, как в этом случае может быть неправильным обоснование решения.Почему в разделе «Вопросы» есть фактическое утверждение о содержании расширения, которое явно ложно?

Что ж, это восходит к двум фактам об этой спецификации расширения.

  1. Он основан на более старом расширении под названием GL_EXT_separate_shader_objects этом расширении вышеприведенное утверждение было верным.Вы не можете использовать пользовательские изменения с отдельными программами.Это потому, что это расширение было полностью написано NVIDIA, и они на самом деле просто собрали вместе какую-то ерунду, чтобы удовлетворить потребности некоторых пользователей.Это не было реальным решением, скорее остановка.

  2. ARB был потрясающе ленивым в создании этой спецификации расширения.Это на самом деле абсурдно, как лениво это было построено.Например, выпуск 2 копируется verbatum из версии EXT, даже если цитируемая часть абсолютно неверна в версии ARB.

    Чтение некоторых других вопросов похоже на погружение в разум параноидального шизофреника.Они делают другие не фактические утверждения, а затем сразу же противоречат друг другу.Это все равно, что сидеть на коленях на встречах АРБ или что-то в этом роде.Функциональность (в основном) в порядке;это сама спецификация расширения, которая является нежелательной.

Я понимаю ваше разочарование.Мой общий способ узнать о функции из расширения - прочитать обзор, а затем перейти к разделу «Проблемы».Обзор дает мне хорошее представление о том, что он должен делать, а раздел «Проблемы» дает мне хорошее представление о том, как выглядит реализация.Все без необходимости разбора через «spec language».

Вы не можете сделать это с этим расширением.Раздел «Проблемы» хуже, чем бесполезный;это активно вводит в заблуждение.Вам придется читать спецификации языка.

...