On Mon, 2009-02-23 at 08:12 -0500, Havoc Pennington wrote:
> Hi,
>
> On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg <b...@o-hand.com> wrote:
> > 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.)
>
> To be sure I'm understanding correctly, you are saying that if we
> always send GL a LoadMatrix instead of say Translate, then the mesa
> code has to "analyze from scratch" to get the inverse and other
> properties, while if we send Translate it knows a lot to start with?
My initial thought was that you should aim to mirror the whole stack by
adding some glPush/PopMatrix calls instead of flattening it into one
server side matrix. This will add traffic, but I'd half expect that if
you are flushing the whole stack in one go without interleaving any
synchronizing requests you can get the whole lot to go in one context
switch. -- I'm wondering if we are about to learn about a whole new
level of GL indirect fail where *everything* synchronizes :-) ... though
it occours to me that this probably is true for a debug build given that
we follow up most requests with glGetError(); It's probably worth
keeping that in mind.
The idea is that by mirring the whole stack you let the driver cache the
inverse at different levels of the stack. By using glLoadMatrix and
always re-using the top of the stack means the driver has chuck
everything away each time.
I guess your idea of calling using glTranslate/glRotate also has
potential to improve things. Looking at mesa I get the impression that
using glLoadMatrix doesn't actually trigger an "analyze from scratch"
function; rather is enables a USE_THE_GENERALISED_PATH flag. :-/ I might
be missing something though...
See _mesa_LoadMatrixf in mesa/main/matrix.c
it calls _math_matrix_loadf in mesa/math/m_matrix.c
which does: mat->flags = (MAT_FLAG_GENERAL | MAT_DIRTY);
There is a _math_matrix_analyse function, which could potentially be
called, but that seems to check for mat->flags & MAT_DIRTY_TYPE so it
doesn't seem like it would analyse the matrix in this case.
>
> (Somewhat frustratingly, because my patch just has the Mesa code in
> it, so we have exactly what Mesa computes already on cogl side!)
yeah, if only GL had a way to load the inverse too :-)
kind regards,
- Robert
--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
