Dynamically loading shaders

Started by
5 comments, last by _the_phantom_ 15 years, 12 months ago
Is it possible, or a good idea even, to dynamically load shaders every time you draw a new frame? Maybe it'd be more exact to say "swap shaders." Like this; 1 Set ShaderA 2 FBO render to texture 3 Set ShaderB 4 Render to window My thought process was I could set one shader for when FBO draws to texture, then swap back to a shader that doesn't do anything but a glFragColor = currentcolor sort of thing. Trying to minimize the amount of complex shader executions I possibly can when processing a texture. So when I scale up the window, so that even though a shader will execute on every pixel at least as the user scales the window it'd only be very simple 1:1 color assignments vs complex trig. (Which I want to limit to the period of time 'complex' shaders are executing to when the FBO is rendering to a texture.) Any thoughts on that? If it's even possible... or recommended.
Advertisement
Its a state change that isn't cheap but most games do dozens of these a frame (shader changes). You don't write one shader thats 40,000 lines long ;-)

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

Cool, yea... lol, makes sense. So then I just hope everything else works out as I expect. :D thanks for the reply.
Since I've never done this before, swapping shaders during run-time, I just took a best guess. Well my CPU had fun with that, shot up quite a bit. Typical CPU usage before was like 10%-13%, now it's some 40%-50%

After the initialization bit where I run through reading the shader files and compiling them, I think use the attach/link/use combo to change the shader. I'm not even sure if that's how a person should be doing this, I didn't find anything through Google on it.

This is basically what I do every frame.

Anyone know of a better way to go about this?

void SetShaderA(){	glAttachObjectARB(p, f); // fragment shader	glLinkProgramARB(p);	glUseProgramObjectARB(p);}



... this might be a bad idea.
You're correct, that's not how you should be using it.

You should think of shaders like normal progams; each time you want to run Word you don't compile, link and execute it. Shaders; same deal.

You compile and link once at start up, then after that you just bind the shader you want when you want to use it.

Word of advice; shader swaps are pretty much the most expensive state change going, as such while you should do them the trick is to keep them down by drawing in batches.

For example, if you have 3 shaders and 6 objects to draw, two using each shader, you should draw the objects in batches so that everything that requires shader 1 is drawn, then shaders 2, then shader 3.
I can't seem to find much information about binding/using multiple shader objects with a program object... do you have any examples or know of any resources?

The only thing I've located so far is that the arb spec says I can do it... I just don't see how.
ah, my bad, a mix of terminolgy; where I wrote 'shader' replace it in your head with 'program'.

Each program consists of a combination of one vertex shader, one fragment shader (and if the hardware supports it one geometry shader). You bind all those together to make your program and that is what you bind when you need to draw.

This topic is closed to new replies.

Advertisement