On Mon, 2009-02-23 at 08:26 +0000, Tomas Frydrych wrote: > Havoc Pennington wrote: > > Anyway, maintaining the matrix client-side does not look super hard > > but it's mostly a series of "matter of taste" judgment calls so if > > anyone could give some guidance on how to approach this... some early > > thoughts: > > I do not particularly like this idea on principle, as you are moving > processing from GPU to CPU. Also, it feels like you are trying to > address driver brokenness in Clutter.
Personally I wouldn't be so worried about this - at least not for the same reason. I think there are good reasons why GLES 2.0 and OpenGL 3.0 scrapped the GL matrix stack APIs entirely. I don't think it's typical for the matrix stack to involve GPU hardware. The biggest disadvantage to dealing with the matrices client side looks to be with tracking the inverse matrix. Calculating the inverse can be a rather expensive operation, and at least looking at the Mesa code it's clear they have quite a bit of smarts involving tagging matrices according to the transformations they represent to allow selecting the most optimal inverse calculation function. (E.g. think of cases like glTranslatef (x,y,z), the inverse is dead simple.) Perhaps in an ideal world; OpenGL would have had API for pushing/popping a matrix along with its inverse too. Also it might be worth noting that although I think OpenGL only needs the inverse matrix for dealing with lighting calculation, and Cogl doesn't expose lighting: - Eventually we will probably want to expose lighting via Cogl so it may become more of an issue. - GLSL vertex programs have a builtin variable for the inverse so that implies; that no matter if you are using lighting or not; if you use GLSL for vertex shading the driver needs to calculate the inverse. kind regards, - Robert -- Robert Bragg, Intel Open Source Technology Center -- To unsubscribe send a mail to [email protected]
