Cost of glLinkProgramARB

OpenGL
1

Hi,

I was just wondering whether anyone has measured the CPU cost of glLinkProgramARB? This is a speculative query, not having tried it myself.

The GL_ARB_shader_objects specs indicate that it does several tasks:

  1. creates an “executable” from the attached shader objects (whatever an “executable” might mean in this context)

  2. some basic checks for mismatches between vertex and fragment programs, and anything in the shaders not supported by the host hardware.

I would expect 2) to be quite cheap, as there is glValidateProgramARB to do more extensive checks.

And I’m not sure what is involved with 1).

Any thoughts?

Thanks,

Mark

2

The cost of the function call is implementation dependent.

Glslang is modeled on the standard C model of compiling and linking. You compile one or more pieces of text into “object files” (shaders). You then link one or more object files into “executables” (programs).

In theory, the cost of linking should be fairly small. However, optimizations (particularly dead code removal, but there are other things) will require more work.

Further, if you’re using an nVidia implementation, you’re in trouble. The compilation step is intended by the spec to do all of the text parsing and so forth, and on nVidia it does (so that it can emit proper errors). However, when the link stage comes around, nVidia implementations recompile the text again. This is legal to the spec, but obviously not the way it should be done for shader compilation performance.

3

OK, so early linking is preferrable to just-in-time then? I was debating whether to delay linking until the desired draw call, but that doesn’t sound like a good thing.

And yeah, I’m on an nVidia implementation :frowning:

Thanks for the info.

4

I think the API itself is to blame for most of this. There’s no way to pre validate things ahead of time, so they probably feel it makes more sense to do it all in one go, as this is the typical scenario. Actually, offline compilation is the preferred way of doing things, but you can’t do that in GLSL yet.

I’m sure many would love to see offline compilation and a means to validate shader inputs ahead of time, so run-time situations like this could be avoided. And I strongly suspect that we’ll see something like this in Mt. Evans.

5

OK, so early linking is preferrable to just-in-time then?
Absolutely.

There’s no way to pre validate things ahead of time, so they probably feel it makes more sense to do it all in one go
Nonsense. The validation isn’t the hard part; it’s just doing a bunch of string compares, which should be easy enough.

The hard part is the optimization of the compiled executables. Inlining where necessary, deciding when to inline, that sort of thing. Global optimization is paramount for performance, so you can’t rely on compile-time inlining. There’s also register assignments and so forth that need to be done.

And, to be honest, even that’s not so hard. It should certainly take less time than text parsing and compiling. The real problem is that nVidia wants to not have to write and maintain two compilers, so they make their Cg compiler do double duty. And Cg doesn’t have the compile/link construct that glslang does, so they force glslang to act like Cg.

Now, what nVidia should have done was make their Cg compiler work like glslang wants to work, and structure Cg around that.

Actually, offline compilation is the preferred way of doing things
Maybe by you, but it’s far from universal.

6

tell it to the hand, korval. tell it to the hand :wink:

7

I would certainly like the option of choosing offline compilation.

But back to early linking I go…

8

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.