search

liballeg / allegro5

The official Allegro 5 git repository. Pull requests welcome!
https://liballeg.org
Other
1.87k stars 283 forks source link

Is OpenGL blending set too often? #622

Open SiegeLord opened 8 years ago

SiegeLord commented 8 years ago

618 fixes setting the blend mode for held drawing, but conceptually, why does it need to be set every time we send a draw call to OpenGL? If this call is indeed expensive, then it is unnecessarily slowing down un-held bitmap drawing and primitives drawing. It seems like it'd be better to just call it exactly when al_set_blender is called and whenever that setting is invalidated.

fatcerberus commented 8 years ago

I can definitely say setting the blend mode is expensive on Intel chipsets - the reason for #618 was that on my laptop with i7-6700HQ when I was trying to find the source of some rendering lag, MSVC's profiler pinpointed _al_opengl_set_blender() as being one of the primary hot paths.

I think I'd agree that it'd be worthwhile to optimize this a bit further.

ghost commented 8 years ago

Are you sure it's not a false flag? Profilers screw up sometimes. I can't see setting a blend mode being expensive relative to drawing, even on Intel chips... but I could always be wrong.

ghost commented 8 years ago

Are you sure it's not a false flag? Profilers screw up sometimes. I can't see setting a blend mode being expensive relative to drawing, even on Intel chips... but I could always be wrong.

ghost commented 8 years ago

Are you sure it's not a false flag? Profilers screw up sometimes. I can't see setting a blend mode being expensive relative to drawing, even on Intel chips... but I could always be wrong.

ghost commented 8 years ago

Are you sure it's not a false flag? Profilers screw up sometimes. I can't see setting a blend mode being expensive relative to drawing, even on Intel chips... but I could always be wrong.

fatcerberus commented 8 years ago

I thought it might be a false flag too, but when I profiled it on my AMD machine that function didn't show up at all. In any case the optimization doesn't hurt and actually helps readability of the Allegeo code since we're now only setting the blend mode in one place instead of two or three.

ghost commented 8 years ago

That's true... Also there's no big loss in over optimization, just seems fishy. It could be that Intel does a flush on blending changes or something like that, too.

ghost commented 8 years ago

I think blending might be invalidated on Android when you pause and resume. Because the GL_DITHER state is invalidated when doing so, blending may be also. Other than that, I can't think of when it would.