CODEWITHSUNDEEP
openglopengl-3
user815129
user815129

Reputation: 2314

Program pipeline shaders variable exchange

I need a vec4 and a float to be passed from the vertex shader to the geometry shader, and then to the fragment shader. The 3 shaders belong to 3 different programs in order to maintain uniform(s) unique, and the 3 are collected in a single Program Pipeline with the geometry shader attached/detached as needed.

The GL_ARB_separate_shader_object extension says:

GLSL has a "rendezvous by name" model for connecting varying output variables to varying input variables of a subsequent shader. With separate shaders, there's no assurance whether a preceding shader will write a given user-defined input varying variable. HLSL9, Cg, and OpenGL assembly extension programs handle this situation by with "rendezvous by API resource" model. In GLSL terms, this means separate GLSL shaders /must/ communicate by built-in varying variables rather than user-defined varying variables.

fine, in the vertex and geometry shaders I used gl_FrontColor for the vec4, and gl_FogFragCoord for the float, reading them in the fragment via gl_FogFragCoord and gl_Color.

It works, fine.. but.. I mean.. cmon, really?

I can understand the rationale behind all this, but it really seems a crappy workaround to me. There is really no other way to make different shaders from different programs communicate each other if they all work in the same Program Pipeline?

Upvotes: 2

Views: 744

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 473272

Let's get this out of the way first: what you read there is not true of that extension/core feature. What follows is an explanation of how it's not true if it's in a spec, and why that incorrect line is here in this spec.

When reading extension specifications, it's important to note the difference between the following:

  • Normative text: This defines how the extension actually works. This is the meat of the text.
  • Descriptive text: This gives a non-binding overview of what the functionality is for. It is non-binding, meaning that the actual normative text could run contrary to it.
  • Meta-text: This explains the reasoning behind the normative text. It also represents the header and footer information (who wrote the extension, what dates it was published, etc).

The Descriptive text for extensions consists of the section called "Overview".

The Normative text, the part that explains how it all works, is defined by the sections "New Procedures and Functions", "New Tokens", and any section of the form, "Additions/Changes to ... Specification".

Everything else is meta-text. But especially the "Issues" section. That section explains some of the reasoning behind decisions made in the spec. What you quoted comes from the "Issues" section. It is non-binding and therefore irrelevant to the actual functionality.

Now, you may wonder how could the reasoning behind a decision be wrong in this case. Why would the Issues section make a factual claim about the contents of the extension that is patently false?

Well, that goes back to two facts about this extension specification.

  1. It is based off of an older extension called GL_EXT_separate_shader_objects. In that extension, the above statement was true. You couldn't use user-defined varyings with separable programs. That's because that extension was written entirely by NVIDIA, and they really just cobbled together some nonsense enough to satisfy some users needs. It wasn't a real solution, more of a stop-gap.

  2. The ARB was stunningly lazy in putting this extension spec together. It's actually absurd how lazily this was constructed. Issue 2, for example, is copied verbatum from the EXT version, even though the quoted part is absolutely incorrect in the ARB version.

    Reading over some of the other Issues is like delving into the mind of a paranoid schizophrenic. They make other non-factual claims, then immediately contradict themselves. It's like having a ring-side seat to the ARB's meetings or something. The functionality is (mostly) fine; it's the extension spec itself that's junk.

I understand your frustration. My general way of learning about a feature from an extension is to read the Overview, then skip to the Issues. The Overview gives me a good idea of what it's supposed to do, and the Issues section gives me a good idea of what the implementation looks like. All without having to parse through "spec language".

You cannot do this with this extension. The Issues section is worse than worthless; it's actively misleading. You'll have to read the spec language.

Upvotes: 4

Related Questions