On Tue, 2004-09-21 at 22:42, Eric Anholt wrote:
> On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote:
> > Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
> > > On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote:
> > > > But got
> > > >
> > > > progs/demos> IperS V1.0
> > > > Written by David B
On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote:
> Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
> > On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote:
> > > Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel:
> > > > Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
> > >
Eric Anholt wrote:
Yeah, it was clear that we used to emit in whatever order, and that
would have been nicer. At this point I'm seeing about 5% CPU time in
EmitState for ipers, which seems pretty hefty for such a small bit
of code, but I didn't see much obvious for improvement.
That's indeed qu
Am Montag, 20. September 2004 22:13 schrieb Ian Romanick:
> Eric Anholt wrote:
> > This gets about a 5% speedup for me in ipers (which I wish was more
> > accurate in its reporting), and doesn't touch glxgears. I didn't have
> > any interesting apps besides glxgears handy to benchmark with.
>
> I
Dieter Nützel wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
rad
Am Dienstag, 21. September 2004 00:00 schrieb Roland Scheidegger:
> Eric Anholt wrote:
> > The attached patch removes the mandatory emits of all state which were
> > happening after each cmdbuf flush. Instead, we set a flag after a
> > cmdbuf flush saying "save the state at the next unlock," which
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
> On Mon, 2004-09-20 at 12:58, Dieter NÃtzel wrote:
> > Am Montag, 20. September 2004 21:52 schrieb Dieter NÃtzel:
> > > Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
> > > > The attached patch removes the mandatory emits of all s
On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote:
> Eric Anholt wrote:
> > The attached patch removes the mandatory emits of all state which were
> > happening after each cmdbuf flush. Instead, we set a flag after a
> > cmdbuf flush saying "save the state at the next unlock," which means
> >
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying "save the state at the next unlock," which means
memcpying the state atoms off. When we actually see the context get
lost
Eric Anholt wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with.
I should be able to give it a spin on viewperf sometime this week...
-
Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel:
> Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
> > The attached patch removes the mandatory emits of all state which were
> > happening after each cmdbuf flush. Instead, we set a flag after a
> > cmdbuf flush saying "save the
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
> The attached patch removes the mandatory emits of all state which were
> happening after each cmdbuf flush. Instead, we set a flag after a
> cmdbuf flush saying "save the state at the next unlock," which means
> memcpying the state atoms
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying "save the state at the next unlock," which means
memcpying the state atoms off. When we actually see the context get
lost
13 matches
Mail list logo
