[Intel-gfx] intel_prepare_render(intel); unhelpful?

[Eric Anholt]

On Mon, 01 Nov 2010 22:19:34 +0000, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> On Mon, 2010-11-01 at 14:41 -0700, Eric Anholt wrote:
> > > I'm going to look at the case I "think" I hit an improvement for and
> > > dissect _why_, then get back to you.
> 
> I'll check this again shortly.. (I recall I was testing this with the
> display lists anyway)..
>  
> > > I'm chasing my code right now to see why it is emitting lots of batches
> > > when not using display lists for benchmarking purposes. I got my figures
> > > muddled up before.. I'm seeing 5 batches / frame when using Display
> > > lists, and nearer 40 when not. (I previously reported the other way
> > > around).
> > 
> > I'd love to know too.  INTEL_DEBUG=state (in the midst of much other
> > spam) dumps out a report of how many times various state changes got
> > flagged, which may highlight a change between the two modes.
> 
> The large number of batches was due to a dumb dumb thing I was doing
> with VBOs.. rather than just discarding the memory after rendering some
> primitives, I was mapping the same VBO and re-uploading, causing
> synchronisation.
> 
> Actually, I had two VBOs and was alternating between them, but was still
> of course causing synchronisation at the map stage. Fixed now, so my non
> display-list code is much faster again.
> 
> I guess it kind of begs the question why the compiled display list needs
> 4 or 5 batches to do what my own code manages in 1.

Display lists are an awful, deprecated feature of GL.  The solution to
them being inefficient is to not use them :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20101102/89ca7f2a/attachment.sig>