PDA

View Full Version : cheep/expensive calls?



CarstenT
01-24-2015, 09:08 AM
Hi good people,

I'm using a 32 bit executable of Code::Blocks ver. 12.11, glew, GLFW3 and OpenGL 3.3 with a core profile.

In "OpenGL Shading Language" ver.3 page 209 the author writes:
quote
A program object contains an executable that will run on the vertex-processor if it contains one or more shader objects of type GL_VERTEX_SHADER that has successfully compiled and linked.
unquote

This doesn't make sense to me .. except that, having two compiled programs to choose between through glUseProgram(..) actually implies that two v-shaders must have been compiled and linked successfully ;o/ it takes time to get all the details ;o/ But, what is the price to pay to swap programs? The SuperBible does not comment on how expensive it is, though he cannot get his arms down on the price of binding buffers.

There is another situation of the same sort: It's possible to make different glfwWindows with each it's own set of callbacks. That would be a real delight if the calls that involves the swap between them are cheep enough (say to separate a userInterface-area from a screen-area) - .. but, that's not how it works, right? Can I assume that it should be used for throwing a pop-up/message-box - or atleast redraws the whole window?

My current GLFW/GLEW-program is erroneous and unstable and I don't want to touch it any further. For the passed year I've tried to learn about C/C++, and I'm much better prepared to start over again. It would be great to get your input on what's expensive and what's not, to have it reflect back on how I choose to structure the code.

I've written a tiny interface for draw-calls and inherited it as an abstract base for a small set of parameter-classes (drawArrays, drawElements .. etc..) that thus can be filled with appropriate call-parameters. It's virtue is, that I can stack all draw-calls into one vector<..> and hoot it off in one for(..).
All depending on what I can get back from you in this thread, I could extend it to take care of all the cheep bindings too! So far the compiler doesn't complaint about the code.

look forward to your comments

PaoloS
01-24-2015, 11:03 AM
Hi CarstenT,

I'll try to reply each question independently:


This doesn't make sense to me .. except that, having two compiled programs to choose between through glUseProgram(..) actually implies that two v-shaders must have been compiled and linked successfully ;o/ it takes time to get all the details ;o/ But, what is the price to pay to swap programs? The SuperBible does not comment on how expensive it is, though he cannot get his arms down on the price of binding buffers.

The main logic is the following: you can attach as many shaders of the same type, but of course each program has 1 entry point for vertex and 1 entry point for pixel shader.
So why can you attach more shaders? Imagine that you have different vertex shaders that all use 1 function. One way you can do it is by having that one function in a file, and then all the other vertex shaders in their respective files. When you create a program, you attach as vertex shader the main vertex shader that you want to execute and the other vertex shader that contains only the shared function.
This could be a reason why you would want to attach more than one type of shader to the same program.
This is also explained really well here:
search in google for "attaching multiple shaders of the same type in a single opengl program

In terms of cost, the only way is to profile. Of course, what you should know is the following: changing shader program is a relatively big pipeline change, but at some point its' unavoidable.
Of course what you should do is order your calls to change shader program as rarely as possible.
Usually a rendering pipeline can be summarized like this:

for each type of geometry in {solid, transparent, blend, ...}
for each shader, set shader
for each model
for each texture change, set object textures
for each object, set object uniforms ( various matrices, uniform parameters, ... )

This is of course a big abstraction but it's the logic of it.




There is another situation of the same sort: It's possible to make different glfwWindows with each it's own set of callbacks. That would be a real delight if the calls that involves the swap between them are cheep enough (say to separate a userInterface-area from a screen-area) - .. but, that's not how it works, right? Can I assume that it should be used for throwing a pop-up/message-box - or atleast redraws the whole window?

I am not sure I understand what your question is here.



My current GLFW/GLEW-program is erroneous and unstable and I don't want to touch it any further. For the passed year I've tried to learn about C/C++, and I'm much better prepared to start over again. It would be great to get your input on what's expensive and what's not, to have it reflect back on how I choose to structure the code.

This is not good. Before worrying about performance you should have a correct program.
First make it work, then make it fast.
In debug mode, you should use glGetError every now and then to make sure that everything is right. This is really important, as you might spend time trying to solve a problem that is actually caused by the pipeline being in a broken state somewhere else.

CarstenT
01-30-2015, 02:12 AM
Hi Paola,
I'm sorry for taking so long to respond to you, but .. this is actually my third response! The first was written before I realized that I actually uses flips between glUseProgram(..) with perfect results. That makes my initial question stupid. The program instabillity happened a year ago (after changing static arrays to std::vector<> and forget to save project first). The other response vanished into thin air when I pressed "new thread" instead of "send" ;o/. I'm not online at home so I have to get out-of-house to mail.
Your response has encouraged me to look through my code yet again. A short while ago I realized that I could use C++11 in Code::Blocks. I've been reading the C++ inventor's books instead of fooling round in the dark - and applying a little of what I learned seems to make the code stabil. That's great, but it's still just a show/test of features .. ready to do the 'real' thing!

Cheers from Carsten

my opengl whereabouts should be in beginners on my latest heureca-moment

CarstenT
06-22-2015, 10:11 AM
hi all,
as for the 'more than one vertex-shader'-question .. I fell on the C notion .. 'as long as there is only ONE main()'
... makes sense ;o)