4 ms·
> Why not: > glTexImage(my_texture_handle, ....); Macro?
by brooksbp 14y ago
> Why not:
> glTexImage(my_texture_handle, ....);
Macro?
- nvoorhies 14y agoYou'll still have the driver doing the mapping from id to handle under the hood. It can get to be north of 25% of cpu cycles spent looking this up in some cases.
- cscheid 14y agoMacros here would make the problem worse. The problem is not notation, it's the call to glBindTexture. It has 1) inescapable measurable performance overhead and 2) affects state that changes the rendering output. So if you macro it, you're forcing yourself to calling glBindTexture even in the cases where that wasn't necessary. (say, if you had just called glBindTexture and knew that the right texture was bound anyway). And, in addition, you have to remember to store the previous state of the bound texture in case someone down the execution path wants to use that value. Macroing things which change global state is, in general, a terrible idea. If you don't macro it, your code has to remember whether the right texture has been bound, and design around that. It can be done for sufficiently simple cases, but the general solution also has performance overhead (checking a local variable before calling glBindTexture will get you into branch misprediction problems) You can imagine complicated solutions like state batching: writing a better, retained-mode domain-specific language atop OpenGL which will analyze the sequences of your calls before making it, and then remove all the unnecessary glBindTexture, etc. calls. But it's a major pain in the ass that simply shouldn't exist.