Since Felix implemented a different heuristics for texture allocation, I
decided to do some measurements on the r100 how fast agp texturing
actually is.
Test conditions are as follows:
Celeron Tualatin [EMAIL PROTECTED] on bx-133 (note this has consequences for AGP
speed, AGP 1x will actually ha
Roland Scheidegger wrote:
Since Felix implemented a different heuristics for texture allocation, I
decided to do some measurements on the r100 how fast agp texturing
actually is.
Test conditions are as follows:
Celeron Tualatin [EMAIL PROTECTED] on bx-133 (note this has consequences for AGP
spee
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
How are AGP texture uploads being done?
The card memory uploads are actually done v
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
> > btw texdown showed that texture transfers to card memory are faster than
> > to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
> > in the best case, though the numbers I got fluctuated quite a bit).
>
> How
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
Am Montag, den 07.02.2005, 12:14 + schrieb Keith Whitwell:
> Felix Kühling wrote:
> > Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
> >
> >>>btw texdown showed that texture transfers to card memory are faster than
> >>>to AGP memory, but not by very much (something like 100MB
Felix Kühling wrote:
Am Montag, den 07.02.2005, 12:14 + schrieb Keith Whitwell:
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100M
Keith Whitwell wrote:
Yes, it doesn't make sense to try and incorporate this code at all. The
texstore.c fixes should help with download of argb textures,
otherwise I don't have a lot new to offer...
These are committed now - let me know if they make a difference.
Keith
Keith Whitwell wrote:
btw texdown showed that texture transfers to card memory are faster
than to AGP memory, but not by very much (something like 100MB/s
vs. 140MB/s in the best case, though the numbers I got fluctuated
quite a bit).
How are AGP texture uploads being done?
The card memory uploa
Roland Scheidegger wrote:
Keith Whitwell wrote:
- Application calls glTexImage - Mesa allocates AGP/card memory and
copies texture directly to final destination (using memcpy().)
I have a couple questions about this. How does this handle things like
glGetTexImage? What happens when there is memo
Keith Whitwell wrote:
I'm still working on the age stuff, but the general strategy is to not
release memory back into the pool until it is guarenteed no longer
referenced. This means hanging onto it for a little while until perhaps
the end of a frame or until the next time you notice the engine
Currently Mesa needs to keep the system memory copy because texture
images in card or agp memory can be clobbered by other apps at any
time - Ian's texture manager will address this.
In the via and sis drivers, texture allocations are permanent, so
I've been able to try a different strategy:
- A
Ian Romanick wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
- Application calls glTexImage - Mesa allocates AGP/card memory and
copies texture directly to final destination (using memcpy().)
I have a couple questions about this. How does this handle things like
glGetTexImage? What happe
Ian Romanick wrote:
Keith Whitwell wrote:
I'm still working on the age stuff, but the general strategy is to not
release memory back into the pool until it is guarenteed no longer
referenced. This means hanging onto it for a little while until
perhaps the end of a frame or until the next time y
>
> I fully support the idea of enabling gart texturing on the r200 driver. If
> the old client texturing code can be kept around as an X config option, so
> much the better, but it shouldn't stand in the way of gart texturing given the
> data above.
I think this is all in the client side of the
On Tue, 2005-02-08 at 02:30 +, Dave Airlie wrote:
> >
> > I fully support the idea of enabling gart texturing on the r200 driver. If
> > the old client texturing code can be kept around as an X config option, so
> > much the better, but it shouldn't stand in the way of gart texturing given
>
>
> But what if you mix clients with different configuration? That's why it
> has to be an X server option I think.
Yes figured this out chatting on IRC today... need to look at it again...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb /
18 matches
Mail list logo
