On Tue, 2009-12-15 at 09:40 -0800, Marek Olšák wrote: 
> On Tue, Dec 15, 2009 at 11:27 AM, Keith Whitwell <[email protected]> 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
> >
> 
> Yes, the same buffer was getting reused every frame causing sync when
> mapping the buffer. However, it will no longer be an issue once
> immediate mode gets implemented. Using DONT_WAIT would probably also
> help here.
> 
> Please, could you possibly look at the patches I sent to you
> approximately 16 hours ago? (there are 7 of them)

The patches look fine to me, Marek, thanks for fixing them up.

Keith





------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to