Alan Hourihane wrote:
>
> On Thu, Apr 05, 2001 at 07:41:34PM +0100, Bill Crawford wrote:
> > Gareth Hughes wrote:
> >
> > > Time for a coffee. Please ignore the last sentence, I don't know what
> > > I'm talking about...
> >
> > I know the feeling ... time I went home for coffee (and sleep :·)
On Thu, Apr 05, 2001 at 07:41:34PM +0100, Bill Crawford wrote:
> Gareth Hughes wrote:
>
> > Time for a coffee. Please ignore the last sentence, I don't know what
> > I'm talking about...
>
> I know the feeling ... time I went home for coffee (and sleep :·)
>
Huh ? It's early.. It's only 8:00p
Alan Hourihane wrote:
>
> On Thu, Apr 05, 2001 at 07:41:34PM +0100, Bill Crawford wrote:
> > Gareth Hughes wrote:
> >
> > > Time for a coffee. Please ignore the last sentence, I don't know what
> > > I'm talking about...
> >
> > I know the feeling ... time I went home for coffee (and sleep :·)
Gareth Hughes wrote:
> Time for a coffee. Please ignore the last sentence, I don't know what
> I'm talking about...
I know the feeling ... time I went home for coffee (and sleep :·)
> -- Gareth
While I think of it, I'd like to have a poke at the Rage Pro code
that was on one of the branches
Bill Crawford wrote:
>
> Gareth Hughes wrote:
>
> > In general, this is true. However:
>
> > 1) All buffers (malloc()'d and DMA) are nicely aligned to at least a
> > cacheline boundary.
>
> malloc() will not always be allocated contiguous physical pages, so
> there is the "colouring" problem
Gareth Hughes wrote:
> In general, this is true. However:
> 1) All buffers (malloc()'d and DMA) are nicely aligned to at least a
> cacheline boundary.
malloc() will not always be allocated contiguous physical pages, so
there is the "colouring" problem ... we might get several pages that
are c
Gareth Hughes wrote:
>
> In general, this is true. However:
>
> 1) All buffers (malloc()'d and DMA) are nicely aligned to at least a
> cacheline boundary.
>
> 2) DMA buffers reside in uncached AGP memory. Hence, caching plays no
> part in the timing of the app.
Time for a coffee. Please ign
Nicholas Leippe wrote:
>
> Ah yes! I totally forgot about cache contention. This would definitely
> explain it.
In general, yes. However, as most of the traffic is being written out
to AGP memory this is less important. Caching effects in the rest of
the driver may result in the differences,
Bill Crawford wrote:
>
> The variation would be in terms of cache usage, e.g. sometimes you
> get buffers that don't collide at all in the cache, other times two
> or more pages happen to collide in the cache and therefore they are
> competing for the same cache lines (leading to more TLB misses
On Wednesday 04 April 2001 18:51, you wrote:
> This may be opening a pointless can of worms,
> but, I'm really curious as to how to explain
> the behavior I'm seeing. Each time I run
> gears, it is perfectly consistent in it's
> speed (+/- .5 FPS) for that instance. But,
> each time I run gears,
On Thursday 05 April 2001 08:25 am, Jeff Epler wrote:
>
> It's likely due to Linux' lack of page coloring.
>
> Let's see if I can get the explanation right ... The L2 cache is typically
> physically mapped, and so for some value N the addresses A and A+N alias
> to the same cache line. N is some
> From: Nicholas Leippe <[EMAIL PROTECTED]>
> On Thursday 05 April 2001 03:08 am, Mike Lincoln wrote:
> > Could it be some buffer is some times allocated (word/page/whatever)
> > aligned and sometimes not?? Tends to make a big difference on Intel..
> Well, I thought about this. But looking at
Nicholas Leippe wrote:
>
> On Wednesday 04 April 2001 06:07 pm, Brian Paul wrote:
> > This isn't really unexpected. Benchmarking any application on
> > a time-sharing operating system can reveal some variation in
> > performance. You never know when another process or the kernel
> > itself will
On Thursday 05 April 2001 03:08 am, Mike Lincoln wrote:
> Could it be some buffer is some times allocated (word/page/whatever)
> aligned and sometimes not?? Tends to make a big difference on Intel..
>
> Mike
Well, I thought about this. But looking at the source (it's pretty
straight forward) th
Could it be some buffer is some times allocated (word/page/whatever)
aligned and sometimes not?? Tends to make a big difference on Intel..
Mike
Jon Pennington wrote:
>
> On Wed, Apr 04, 2001 at 06:30:51PM -0600, Nicholas Leippe wrote:
>
> > where it varies across the entire range of possibil
On Wed, Apr 04, 2001 at 06:30:51PM -0600, Nicholas Leippe wrote:
> where it varies across the entire range of possibilities
> (which would account for various load factors). But instead
> what I observe is that it is extremely consistent in any
> one given run, only varying between different ru
> On Wednesday 04 April 2001 06:07 pm, Brian Paul wrote:
> > This isn't really unexpected. Benchmarking any application on
> > a time-sharing operating system can reveal some variation in
> > performance. You never know when another process or the kernel
> > itself will need some CPU cycles.
> >
On Wednesday 04 April 2001 06:07 pm, Brian Paul wrote:
> This isn't really unexpected. Benchmarking any application on
> a time-sharing operating system can reveal some variation in
> performance. You never know when another process or the kernel
> itself will need some CPU cycles.
>
>
> -Brian
Nicholas Leippe wrote:
>
> This may be opening a pointless can of worms,
> but, I'm really curious as to how to explain
> the behavior I'm seeing. Each time I run
> gears, it is perfectly consistent in it's
> speed (+/- .5 FPS) for that instance. But,
> each time I run gears, it is consistent a
This may be opening a pointless can of worms,
but, I'm really curious as to how to explain
the behavior I'm seeing. Each time I run
gears, it is perfectly consistent in it's
speed (+/- .5 FPS) for that instance. But,
each time I run gears, it is consistent around
a different value that ranges fr
20 matches
Mail list logo
