On Tue, 2009-12-15 at 10:27 +0000, Keith Whitwell wrote: > On Tue, 2009-12-15 at 01:49 -0800, Marek Olšák wrote: > > On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell <[email protected]> wrote: > > > 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. > > > > > > Shouldn't gears upload its vertices one time only and then leave them > > > resident in VRAM? > > > > > > Keith > > > > > > > > > > I meant the clear path with a quad using immediate mode, that made the > > difference in comparison with a straightforward VBO path. > > OK, understood. > > I'm interested to understand why the VBO path is slow. Is it the > allocation of the VBO itself? Mapping & uploading the vertices? > Command submission (the extra reloc)? > > It seems to me that none of these should be taking half your time. In > fact, it makes me wonder if there wasn't something else going on -- eg. > was the same buffer getting reused to hold those 4 vertices frame after > frame, resulting in a sync when the driver tried to map the buffer? > > That could be happening in the state tracker or in the driver, I guess. > > 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
