On Thu, 10 Feb 2005 20:14:00 -0800, Eric Anholt <[EMAIL PROTECTED]> wrote:
> Is there evidence that this is/would be in fact faster?
That's how the networking drivers work and they may be the fastest
drivers in the system.
But, it has not been coded for AGP so nobody knows for sure. It has to
be f
> > it. Instead mark it's page table entries as copy on write. Get the
> > physical address of the page and set it into the GART. Now the GPU can
> > get to it with zero copies. When you are done with it, check and see
> > if the app caused a copy on write, if so free the page, else just
> > remove
On Thu, 2005-02-10 at 22:23 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:59:29 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote:
> > That should allow a straight-copy from data you create to memory card
> > the can texture from, which is about as good as possible.
>
> If you have a big AGP apertur
On Thu, 10 Feb 2005 21:59:29 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote:
> That should allow a straight-copy from data you create to memory card
> the can texture from, which is about as good as possible.
If you have a big AGP aperture to play with there is a faster way.
When you get the call to
Dave Airlie wrote:
A better scheme for a movie player would be to create a single texture
and then keep replacing it's contents. Or use two textures and double
buffer. But once created these textures would not move in the LRU list
unless you started something like a game in another window.
if we s
Felix Kühling wrote:
I don't think my algorithm is much more complicated. It can be
implemented by gradual improvements of the current algorithm (freeing
stale texture memory is one step) which helps avoiding unexpected
performance regressions. At the moment I'm not planning to rewrite it
from scra
Jon Smirl wrote:
AGP 8x should just be able to keep up with 1280x1024x24b 60
times/sec.
AGP 4x should be enough. Remember I got 600MB/s max throughput. Not with
24bit textures though, the Mesa RGBA-BGRA conversion takes WAY too much
time to achieve that.
How does mesa access AGP memory from the CP
AGP 8x should just be able to keep up with 1280x1024x24b 60 times/sec.
How does mesa access AGP memory from the CPU side? AGP memory is
system memory which the AGP makes visible to the GPU. Are we using
the GPU to load textures into AGP memory or is it being done entirely
on the main CPU with a m
>
> A better scheme for a movie player would be to create a single texture
> and then keep replacing it's contents. Or use two textures and double
> buffer. But once created these textures would not move in the LRU list
> unless you started something like a game in another window.
if we supported
Felix Kühling wrote:
I simplified this idea a little further and attached a patch against
texmem.[ch]. It frees stale textures (and also place holders for other
clients' textures) that havn't been used in 1 second when it runs out of
space on a texture heap. This way it will try a bit harder to put
Am Donnerstag, den 10.02.2005, 17:40 -0500 schrieb Jon Smirl:
> On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> > This scheme would give good results with movie players that need fast
> > texture uploads and typically use each texture exactly once. It would
>
> Movi
On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> This scheme would give good results with movie players that need fast
> texture uploads and typically use each texture exactly once. It would
Movie players aren't even close to being texture bandwidth bound. The
demote
On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> This means you copy a texture when you don't know if or when you're
> going to need it again. So the move of the texture may just be a waste
> of time. It would be better to just kick the texture and upload it again
> la
Am Donnerstag, den 10.02.2005, 15:31 -0500 schrieb Jon Smirl:
> I haven't looked at the texture heap management code, but one simple
> idea for heap management would be to cascade the on-board heap to the
> AGP one. How does the current algorithm work? Does an algorithm like
> the one below have me
I haven't looked at the texture heap management code, but one simple
idea for heap management would be to cascade the on-board heap to the
AGP one. How does the current algorithm work? Does an algorithm like
the one below have merit? It should sort the hot textures on-board,
and single use textures
Am Mittwoch, den 09.02.2005, 22:12 +0100 schrieb Felix Kühling:
> Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger:
[snip]
> > Performance with gart texturing, even in 4x mode, takes a big hit
> > (almost 50%).
> > I was not really able to get consistent performance results wh
Felix Kühling wrote:
Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger:
Some more numbers, this time from a 9000Pro (64MB). In contrast to the
quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth
(128bit/275Mhz DDR). Not to mention the chip is certainly faste
Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger:
> Some more numbers, this time from a 9000Pro (64MB). In contrast to the
> quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth
> (128bit/275Mhz DDR). Not to mention the chip is certainly faster too.
> Test s
Is there a tool for dumping stats on which textures are in which heap?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which p
Some more numbers, this time from a 9000Pro (64MB). In contrast to the
quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidth
(128bit/275Mhz DDR). Not to mention the chip is certainly faster too.
Test sytem is also faster though, A64 3000+ socket 754, 3.2GB/s system
memory band
20 matches
Mail list logo
