On Mon, 01 Nov 2010 22:19:34 +0000, Peter Clifton <[email protected]> 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 :)
pgpVDhv1Qhjlx.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
