On Wed, 2009-09-23 at 01:41 -0700, Dave Airlie wrote:
> >
> > Hey all,
> >
> > So in mesa for swtcl cases we emit vertices to DMA, and set a driver
> > internal dma.flush hook, we also set
> > ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES;
> >
> > The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
> > call.
> >
> > I'm not sure when this ever worked but I assume it did at one stage in
> > r100 driver since I haven't really changed this code flow, I'm
> > contemplating doing something like the below but maybe someone can
> > say when this all got broken.
>
> any insights? Keith?
Hmm, it would seem like you'd need this if:
a) you have a hw vertex buffer that you're incrementally extending as
new vertices arrive
b) you are delaying emitting the draw packet until you know how many
vertices you put in that buffer, and
c) you don't have any other mechanism to ensure that draw packet doesn't
attempt to span hw statechanges.
IE. if you're optimistically trying to combine incoming primitives into
single draw packets, and don't have code to flush that in response to
state-changes, then this patch makes sense.
If the above doesn't describe your situation, I don't think you want
this.
However, even if it does, note that you'd be better off trying to figure
out when a *real* hardware statechange is about to happen before tying
off the old draw packet, as Driver.FlushVertices is going to get called
on every putative mesa statechange, many of which won't result in
hardware statechanges.
In fact, thinking about it, if you flush on every call to this function,
you basically defeat the optimization it seems you're trying to
implement, because the incoming vertices you're trying to combine will
almost always have a mesa statechange between them -- there's no other
reason mesa would break them up, and Mesa already tries to combine
incoming application draws that aren't separated by statechanges.
So if you do this, really you'd be just as well served with an eager
emit of the draw packet & forget about trying to be lazy.
Keith
> Dave.
>
> >
> > Dave.
> >
> > diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c
> > b/src/mesa/drivers/dri/radeon/radeon_context.c
> > index 8f4485a..d103ac5 100644
> > --- a/src/mesa/drivers/dri/radeon/radeon_context.c
> > +++ b/src/mesa/drivers/dri/radeon/radeon_context.c
> > @@ -204,6 +204,14 @@ static void r100_init_vtbl(radeonContextPtr radeon)
> > radeon->vtbl.emit_query_finish = r100_emit_query_finish;
> > }
> >
> > +static void radeon_flush_vertices(GLcontext *ctx, GLuint flags)
> > +{
> > + r100ContextPtr rmesa = R100_CONTEXT(ctx);
> > + if (rmesa->radeon.dma.flush)
> > + rmesa->radeon.dma.flush(ctx);
> > + vbo_exec_FlushVertices(ctx, flags);
> > +}
> > +
> > /* Create the device specific context.
> > */
> > GLboolean
> > @@ -329,6 +337,7 @@ r100CreateContext( const __GLcontextModes *glVisual,
> > _swsetup_CreateContext( ctx );
> > _ae_create_context( ctx );
> >
> > + ctx->Driver.FlushVertices = radeon_flush_vertices;
> > /* Install the customized pipeline:
> > */
> > _tnl_destroy_pipeline( ctx );
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry® Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Mesa3d-dev mailing list
> > Mesa3d-dev@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >
> >
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
