Im one of the people that beleive that this should be solved in a “is it fast enough” way, that is test it.
But hardware and drivers nowadays contains many pitfalls and strange combinations can make the path jump from hardware to software, or perhaps even a mixed mode ( i guess depthtest will be in hw even if the texturing is software?)
So in the light of this it pretty nice to find out about where in the code we switch mode, since a startup test of different things might tell you its fast enough but another combination in the code will not be fast enough.
To make it easier to follow the flow and to narrow down the code to check i suggest a glget constant that could answer ‘was the previous render done in hardware/software/mixed mode’.
glGetIntegerv(GL_RENDER_PATH, v);
where v is one of the constants above.
it should be valid to call after a render command or if its possible, after every state change
I think there is a need for something like this. But the problem seem to be the definition of “mixed mode” : in fact everything can end up in this category, and it would be quite meaningless.
Maybe hardware vendors will not always play the game, that is, reporting “yes, this is hardware super accelerated mode, go ahead!” just so that the hardware looks good from a quit check.
this sounds like something better suited to a query. seems like opengl’s query support could be expanded to include a slew of profile type queries. though i’m not so sure about a “render path” as such.
perhaps something more along the lines of generic pipline performace/timing info, like you have in d3d. though i don’t know how well this translates in the opengl rubric. but it seems to me the query mechanism would be relatively easy to extend, api-wise anyway.
a need for a rendered triangle count came up in another forum here that would fit neatly into the query category too.