From: Keith W. <ke...@tu...> - 2005-02-09 21:59:19
|
Felix K=FChling wrote: > Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger: >=20 >>Some more numbers, this time from a 9000Pro (64MB). In contrast to the=20 >>quite slow 7200sdr with only 2.6GB/s ram, this one has 8.8GB/s bandwidt= h=20 >>(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=20 >>memory bandwidth. >>Desktop resolution 1280x1024, quake3 windowed 1024x768. >>The hacks required to disable the heaps are exactly the same as those=20 >>used on r100 (except of course the nr_heaps assertion had to go..., yes= =20 >>this hack DOES break the client stuff). >>Local texture size is 35MB, unless otherwise noted (I just changed the=20 >>allocation scheme in the ddx driver, so only 1 framebuffer worth of=20 >>pixmap cache is used instead of 3, btw without really any noticeable=20 >>impact on 2d performance). GART size is 32MB unless specifically stated= . >> >>Desktop resolution 1280x1024, quake3 windowed 1024x768. >> >>AGP 4x, local: 125 fps >>AGP 4x, both: 80-123 fps >>AGP 4x, gart only: 68 fps >>AGP 1x, local: 115 fps >>AGP 1x, gart only: 21 fps >> >>Some rtcw (demo checkpoint) results too (fullscreen 1024x768). >>AGP 4x, local: 70 fps >>AGP 4x, local 45MB: 85 fps >>AGP 4x, both: 62-77 fps >>AGP 4x, both, gart 64MB: 58-68 fps >>AGP 4x, gart only, 64MB: 47 fps >>AGP 1x, local: 56 fps >>AGP 1x, gart only: 14 fps >> >=20 >=20 > Thanks for these numbers. They show that the current memory management > strategies are far from perfect. Read on below for some ideas how to > improve it. >=20 >=20 >>texdown AGP 4x gart: 230MB/s >>texdown AGP 4x local: 650MB/s! >>texdown AGP 1x gart: 117MB/s before q3, 89MB/s after q3 (?) >>texdown AGP 1x local: 265MB/s!!! >> >>There seemed to be a problem with gart texturing and AGP modes lower=20 >>than 4x, agpgart reported "Putting AGP V2 device at 0000:00:00.0 into 0= x=20 >>mode", glxinfo still reported AGP 1x and 2x, respectively. 1x and 2x=20 >>results were identical, and to put it simply, the results downright=20 >>appalling. This may be a problem with agpgart (using the version from=20 >>kernel 2.6.10). However, I was amazed at the texdown performance to=20 >>local graphics memory, as it's VERY close to the theoretical limit.=20 >>texdown performance with AGP 4x was also quite good. >=20 >=20 > Keith committed a fastpath for Mesa's texstore functions that reduced > the CPU-overhead of the rgba 32bit texture uploads significantly. I think the radeon actually uses a rgba8888 intnernal format, unlike the=20 argb8888 everything else does (which was the subject of the commit).=20 That means mesa will upload GL_RGBA textures with a straight memcpy,=20 though it still hits a very slow path with "near miss" texture formats. Keith |