On Wed, 2008-08-20 at 10:16 +0300, Michael Boccara wrote: > Neil Roberts wrote: > > On Tue, 2008-08-19 at 23:36 +0300, Michael Boccara wrote: > > > > I had the same problem when making the ClutterMD2 renderer. You can work > > around it by saving some of the GL state before doing your custom GL > > rendering and then restoring it afterwards. Please take a look at the > > clutter_md2_data_save/restore_state functions here: > > > > http://tinyurl.com/5dn3bv > > > > > Thanks Neil. This is a good reference code, relevant for whoever wants > to make actors based on complex geometry. > I got the idea: you are basically doing what cogl is doing, i.e. > managing a LIFO stack of GL states. > The problem with this workaround is that you do glGet* upon every > frame, which is flushing/finishing the GL pipeline, causing > performance issues. I'd be rather worried if your GL driver is causing a hardware flush for calling glGet* ? Broadly speaking a GL driver will maintain a large state machine e.g. using a plain C struct {} and perhaps maintain some dirty flags for various members. If you glEnable somthing then the dirty flag could be set and the value updated (no HW flush here), and if you just glGet somthing that should simply read some particular struct member. When the driver comes to do the next frame it uses the dirty flags to determine what state changes need to be issued to the HW and continues to emmit the geometry + kick the render etc.
> But I guess I will manage with this approach until I get to the > performance tuning phase. > > > > Is there a way to cancel Cogl's internal GL state cache ? > > > > > > > Not at present. There was talk of providing functions in Cogl to help > > with this but it needs some more discussion before being implemented > > because it's not always obvious what state should be preserved. > > Sometimes you may want the GL state to be set to a known consistent > > state and sometimes you want some Cogl settings to remain (such as > > cogl_enable_depth_test or a shader). > > > > > I still don't agree with the choice of having Cogl manage a cache of > the GL state. > Any good OpenGL driver does this job internally in order to achieve > good performance against competitors. > Giving this responsibility to the cogl layer causes more problems than > it solves. > Or do I miss another motivation behind this ? Certainly there are pros and cons. I think typically the GL functions would have marginally greater overheads in the single threaded use case (most of the time for Clutter) since GL implicitly has to do a thread local storage lookup for each GL call, and possibly take a lock. That used to be quite expensive, though I guess these days with NPTL it might not be such an issue. Also I wouldn't be so hopeful that all GL/GLES drivers are "good" yet sadly. Certainly a number of smaller GPU vendors creating GLES capable hardware are less likely to have very well optimised drivers. Currently our cache supports a different interface than the glEnable/Disable approach of OpenGL. We currently have cogl_enable() (The name is a bit misleading because it's not synonymous with glEnable) that takes a complete bitmask of the state we want enabled which will determine the appropriate glEnables/Disables etc to call. I.e. because Cogl's state management requirements have been quite simple so far it's been convenient for us to be able to setup all our enables in one go via a single bitmask. > > Another issue, when surrendering to using cogl for custom actors, is > that only a very small set of cogl functionalities is exposed in the > exported cogl.h. For example, even cogl_enable() is hidden in the > internals of the source tree. Currently cogl_enable is purposely not public :-) As mentioned above our requirements internally to Cogl have been quite simple so far, and certainly cogl_enable reflects that. It is not a scaleable interface at all, and for example we still haven't determined how to manage multiple texture units with this approach. Basically it's not possible to flatten all the GL enums that can be enabled/disabled etc into one bitmask. Brainstorming this a bit with others, we have the following proposal: 1) We remove cogl_enable. (Internally it only manages 4 flags a.t.m) 2) We expose new cogl_enable and cogl_disable functions to be used like glEnable/glDisable that will sit on top of an internal cache. 3) We expose a new cogl_flush_cache func that commits the cache to GL 3) We expose a new cogl_dirty_cache func that lets you invalidate cogls cache. 4) Re-internaly re-work code in terms of these new funcs in place of the current cogl_enable. This should support a complete break out into GL (even into code you can't easily modify) since you just need to call cogl_dirty_cache to invalidate everything. Do you think that could help your use case? kind regards, - Robert -- To unsubscribe send a mail to [EMAIL PROTECTED]
