On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote: > On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson > <[email protected]> wrote: > > As far as immediate verts, why don't we just add support to r300g to switch > > to immediate mode for small VBOs? > > > > Posting from a mobile, pardon my terseness. ~ C. > > > > Corbin, > > that seems reasonable, and it's the reason I killed the draw_quad > function. BTW immediate mode doubles the performance in glxgears. > > To others: > I noticed that there is a weird optimization in u_gen_mipmaps. It > allocates a large vertex buffer and uses small chunks of it to render > consecutive quads (one for each mipmap level and cubemap face). If we > implement switching to immediate mode, it would be nice for VBOs to be > as small as possible so that the driver can easily recognize the most > efficient path. The simplest solution (4 vertices in a VBO) may end up > being the fastest one here.
I think it was a bit of a bad optimization -- to make it really work properly we'd want to map_buffer_range() with DONT_WAIT or similar. It was intended to avoid lots of buffer creations, but we ended up getting flushes/waits when we try to append vertices to a VBO which is already in flight. We don't get enough notification to avoid this, so the only way to fix is with map_buffer_range() using DONT_WAIT or similar. On balance, it would be better just to pass the vertices in a user buffer and let the driver decide how to deal with them. Keith ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
