Radeon X800GTO and X550 on Debian Etch experience report
Anton Ertl
installed Debian Etch for AMD64 on it. We later also tested a
Connect3D Radeon X550 (fanless) on that box.
Installation went fine, as usual, except that it stumbled on
generating the X configuration: It guessed that the card needs the
"ati" driver, which was wrong, resulting in X startup failing ("no
device found" or somesuch). After changing the driver manually to
"radeon" (in /etc/X11/xorg.conf), X started fine. This problem might
be specific to this card.
The nice surprise we got was that the R300 driver for Mesa (OpenGL) is
already included in one of the packages we installed anyway, so we got
hardware-accelerated 3D performance without further ado.
We did not get any numbers out of the glxgears from the distribution
(Why not? All other glxgears variants I know output an FPS number
every 5 seconds). Anyway, glxgears produced only about 60% CPU load
(for one core, with the X800GTO) with the default size, so it
obviously is using the hardware acceleration, and is limited by it.
Next, we installed planetpenguin-racer (ppracer, a descendent of
tuxracer), turned on all the non-experimental graphics options, used a
full screen with 1280x1024 resolution, and ran the game. This
produced a framerate of 80-100 FPS.
Then we changed the graphics card and put in the Connect3D Radeon
X550, which is fanless. The system started without needing a
reconfiguration or anything. Glxgears now showed about 30% CPU load
in the default size (so the X550 is about half as fast as the Palit
X800GTO for this benchmark; the Palit X800GTO has slower memory
(350MHz) than a regular X800GTO (490MHz), so for another card the
speedup may be even greater). When playing ppracer, the frame rate
was in the 50-65fps range.
Conclusion and recommendations:
- The r300 driver appears to be quite usable, and is included in
Debian etch. This was a pleasant surprise.
- If you want a fanless graphics card where hardware 3D is supported
with free drivers, the fastest card you can still get is a fanless
X550 (you might also try to look for fanless X700s or faster cards,
but you probably need to look for second-hand ones, as new ones are
no longer sold AFAIK). It is even hard to get a fanless X550 (or a
fanless non-SE X300): the Connect3d I got is fanless, and supposedly
Sapphire has a fanless model (but I did not find it on their homepage
when I looked).
- If you can live with a fan, but require free drivers and hardware 3D
support, anything up to the X850XT should do fine, but many
manufacturers are phasing these cards out.
- If you want to support gaphics chip makers that provide the
necessary information to write 3D drivers, then Intel chipset
graphics (GMA950 in i945G, GMA3000 in i965G) are the favourite
choice nowadays (but not very powerful AFAIK). Also, you could buy
an ATI R200-based card (anything up to the Radeon 9250), but they
are not available for PCIe (a PCI card would be an option for many
PCIe mainboards, though).
- In any case, if you care for 3D performance, don't buy a card with a
narrow memory interface (often called SE, LE, Hypermemory, but
sometimes only recognizable by looking at the presence of absence of
the "128-bit memory interface" (for medium-range cards) or "256-bit
memory interface" (for higher-end cards) spec).
For something completely different: the motherboard on the box (some
i945-based Asus board) includes a Realtek 8168b/8111b Gigabit Ethernet
interface, which is recognized and supported by IIIRC Ubuntu 6.10 with
an r1000 driver, but not by Debian etch. We solved this problem by
plugging in a cheap Realtek 8169 card, which is supported by the r8169
driver in Debian Etch.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
snd...@gmail.com
Anton Ertl wrote:
> We recently got a Core 2 Duo box with a Palit Radeon X800GTO, and
> installed Debian Etch for AMD64 on it. We later also tested a
> Connect3D Radeon X550 (fanless) on that box.
That thing has 15 pin analog vga out in addition to the digital!
Awesome!
> Installation went fine, as usual, except that it stumbled on
> generating the X configuration: It guessed that the card needs the
> "ati" driver, which was wrong, resulting in X startup failing ("no
> device found" or somesuch). After changing the driver manually to
> "radeon" (in /etc/X11/xorg.conf), X started fine. This problem might
> be specific to this card.
>
> The nice surprise we got was that the R300 driver for Mesa (OpenGL) is
> already included in one of the packages we installed anyway, so we got
> hardware-accelerated 3D performance without further ado.
>
> We did not get any numbers out of the glxgears from the distribution
> (Why not? All other glxgears variants I know output an FPS number
> every 5 seconds). Anyway, glxgears produced only about 60% CPU load
> (for one core, with the X800GTO) with the default size, so it
I think top shows cumulative CPU utilization. top that came with FC6
does not show
breakdown per core. For dual core 0.60 is about 1.20 for a single core
-> CPU bound for sure.
I'd be very surprised if glxgears were limited by the X800. In fact,
I'm very surprised you
got 30% cpu utilization with glxgears on X550. What tool did you use to
measure cpu utilization?
> obviously is using the hardware acceleration, and is limited by it.
I don't see how that could be possible with the low polygon count
per frame as with glxgears. If glxgears is ever gpu bound even on
something
as slow as intel gma950/x3000, let alone a radeon it's most likely a
problem
with the dri drivers or mesa. In radeon case it's probably the lack of
documentation
for the hardware. One more reason to give your money to Intel.
> Next, we installed planetpenguin-racer (ppracer, a descendent of
> tuxracer), turned on all the non-experimental graphics options, used a
> full screen with 1280x1024 resolution, and ran the game. This
> produced a framerate of 80-100 FPS.
>
That's probably a much better test for a half decent gpu than glxgears.
John-Paul Stewart
>
> I think top shows cumulative CPU utilization. top that came with FC6
> does not show breakdown per core.
That depends on the version of top and the configuration. Most modern
versions of top will default to cumulative but can be toggled to per-CPU
(or per-core, as the case may be) with the "1" key (that's number one).
Anton Ertl
>
>Anton Ertl wrote:
>> We recently got a Core 2 Duo box with a Palit Radeon X800GTO, and
>> installed Debian Etch for AMD64 on it. We later also tested a
>> Connect3D Radeon X550 (fanless) on that box.
>
>That thing has 15 pin analog vga out in addition to the digital!
>Awesome!
Really? Seems pretty normal to me. And in any case, if you have a
full DVI-I port, it also has analog (DVI-A) output in addition to
digital (DVI-D); although I have read about DVI ports that are
digital-only or where the analog signal is so bad that it is mostly
useless. There are DVI-A to VGA adapters, but they are relatively
expensive unless you get them with your graphics card (which is pretty
rare nowadays).
>> We did not get any numbers out of the glxgears from the distribution
>> (Why not? All other glxgears variants I know output an FPS number
>> every 5 seconds). Anyway, glxgears produced only about 60% CPU load
>> (for one core, with the X800GTO) with the default size, so it
>
>I think top shows cumulative CPU utilization. top that came with FC6
>does not show
>breakdown per core. For dual core 0.60 is about 1.20 for a single core
>-> CPU bound for sure.
>I'd be very surprised if glxgears were limited by the X800. In fact,
>I'm very surprised you
>got 30% cpu utilization with glxgears on X550. What tool did you use to
>measure cpu utilization?
We used the %CPU column of top. On Debian at least that shows the
utilization of a single core. If you run to CPU-hogging processes on
a dual-core machine, you get two times 100%, e.g.:
top - 22:03:42 up 7 days, 5:17, 7 users, load average: 1.57, 0.53, 0.19
Tasks: 97 total, 3 running, 94 sleeping, 0 stopped, 0 zombie
Cpu(s):100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4052000k total, 768384k used, 3283616k free, 164508k buffers
Swap: 7815480k total, 0k used, 7815480k free, 408532k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20481 anton 25 0 13600 860 440 R 100 0.0 1:09.61 gforth
20482 anton 25 0 13600 860 440 R 100 0.0 1:03.85 gforth
...
Ah, I see what you mean: If you look at the "Cpu(s):" line and you
have a single CPU-hogging process, you get a 50% utilization there:
Cpu(s): 50.0%us, 0.0%sy, 0.0%ni, 50.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4052000k total, 768384k used, 3283616k free, 164516k buffers
Swap: 7815480k total, 0k used, 7815480k free, 408524k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20482 anton 25 0 13600 860 440 R 100 0.0 3:16.02 gforth
1 root 16 0 6120 632 520 S 0 0.0 0:01.60 init
....
We did not look at the "CPU(s):" line, but instead we looked at the
%CPU column of the process' line.
>I don't see how that could be possible with the low polygon count
>per frame as with glxgears.
How else? Few, but big polygons mean that the CPU has relatively
little to do per frame, but the GPU still has a lot of area to fill.
Ok, it's still less work per frame than a complex scene, but that just
means that we get thousands of FPS.
We varied the work that the GPU had to do by making the window larger
(CPU utilization went down), or by covering it partly or fully, or
even iconizing it (CPU utilization went up).
Anton Ertl
>We did not get any numbers out of the glxgears from the distribution
Eventually we found out that there is a "-printfps" flag; with the
default window size the X800GTO produced about 3650 fps.
The other thing we tested was Unreal Tournament 2004, playing
CTF-GrassyKnoll. At first we go only about 20FPS irrespective of the
settings; then we looked at the warnings that are output at the start,
and added
Option "GARTSize" "64"
to 'Section "Device"' of the xorg.conf file. The resulting framerate
with 1280x1024 and most settings on Normal is about 50fps for the
view we used as benchmark (faster for lower resolutions).
On Windows the benchmark view gets about 150fps with similar settings,
so there is still quite a bit more performance to be had from this
hardware. I guess we should work through some of the stuff on
<http://dri.freedesktop.org/wiki/ATIRadeon>, and this will hopefully
lead to better performance.
Shadow_7
> default window size the X800GTO produced about 3650 fps.
You might also try the ati 8.31.5 driver. One change entry says it's
closer to POSIX support now. So I guess it'll install the stuff in the
right place this time. (in theory)
Vladimir Florinski
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>We did not get any numbers out of the glxgears from the distribution
>
> Eventually we found out that there is a "-printfps" flag; with the
> default window size the X800GTO produced about 3650 fps.
>
So, let's see. You bought a $140 video card that gives you 3600 FPS when
a $110 Nvidia 6800 will easily put out 10,000 FPS. I guess this is
something to be proud about...
--
Vladimir
Henrik Carlqvist
> Eventually we found out that there is a "-printfps" flag; with the
> default window size the X800GTO produced about 3650 fps.
Whoha! We have a new top performer. Please report that number with your
configuration to http://www.free3d.org/
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
ro...@variousus.net root@localhost
Anton Ertl
>On Fri, 08 Dec 2006 10:50:29 +0000, Anton Ertl wrote:
>> Eventually we found out that there is a "-printfps" flag; with the
>> default window size the X800GTO produced about 3650 fps.
>>
>
>So, let's see. You bought a $140 video card
I did not buy it, and it cost about EUR75.
> that gives you 3600 FPS when
>a $110 Nvidia 6800 will easily put out 10,000 FPS.
I expect that an Nvidia 6800 will produce about 200 FPS on this
machine with free drivers.
snd...@gmail.com
Anton Ertl wrote:
> snd...@gmail.com writes:
> >
> >Anton Ertl wrote:
> >> We recently got a Core 2 Duo box with a Palit Radeon X800GTO, and
> >> installed Debian Etch for AMD64 on it. We later also tested a
> >> Connect3D Radeon X550 (fanless) on that box.
> >
> >That thing has 15 pin analog vga out in addition to the digital!
> >Awesome!
>
> Really? Seems pretty normal to me. And in any case, if you have a
Not on high end cards (which X550 is not) it is not these days.
Samsung 931 chmazung 931 I'm a hardcore CRT fan :-)
> How else? Few, but big polygons mean that the CPU has relatively
> little to do per frame, but the GPU still has a lot of area to fill.
I think what you really tested is the GPU memory bandwidth and it was
lower than on X800.
The X550 I ordered a day or two ago came in 128MB SE variety : half the
bandwidth of X800
or even less (SE stands for Shittiness Extended?). Does your X550 also
have the crippled memory interface?
>
> Ok, it's still less work per frame than a complex scene, but that just
> means that we get thousands of FPS.
low polygon count test with glxgears is useless imo.
It's the pathetic linux equivalent of 3dmark I guess :-)
>
> We varied the work that the GPU had to do by making the window larger
> (CPU utilization went down), or by covering it partly or fully, or
> even iconizing it (CPU utilization went up).
>
Yep. Amazing how good decade old designs like g200/400/450/550 are
2d-wise
compared to the "modern" gpus, don't you think? ;-)
Anton Ertl
>
>Anton Ertl wrote:
>> How else? Few, but big polygons mean that the CPU has relatively
>> little to do per frame, but the GPU still has a lot of area to fill.
>
>I think what you really tested is the GPU memory bandwidth and it was
>lower than on X800.
>The X550 I ordered a day or two ago came in 128MB SE variety : half the
>bandwidth of X800
>or even less (SE stands for Shittiness Extended?). Does your X550 also
>have the crippled memory interface?
No. I have a 256MB card with 128-bit memory interface
<http://www.connect3d.com/products/pcie_x550.htm>. The memory
bandwidth is still lower than for the Palit X800GTO (250MHz on the
X550, 350MHz on the Palit X800GTO).
>> Ok, it's still less work per frame than a complex scene, but that just
>> means that we get thousands of FPS.
>
>low polygon count test with glxgears is useless imo.
I guess that this is the reason why they disabled the FPS output by
default. I find it still useful to see whether the 3D acceleration is
actually working.
>> We varied the work that the GPU had to do by making the window larger
>> (CPU utilization went down), or by covering it partly or fully, or
>> even iconizing it (CPU utilization went up).
>>
>Yep. Amazing how good decade old designs like g200/400/450/550 are
>2d-wise
>compared to the "modern" gpus, don't you think? ;-)
My interpretation is that CPU utilization went up because the GPU no
longer had as much area to fill, so the CPU no longer had to wait as
long for it, and could start the next iteration sooner; nothing to do
with 2D performance.
Vladimir Florinski
> I expect that an Nvidia 6800 will produce about 200 FPS on this
> machine with free drivers.
>
No, it will produce about 10,000 FPS with the free nvidia driver (as in
free from stupidity and incompetence)
--
Vladimir
Henrik Carlqvist
>> I expect that an Nvidia 6800 will produce about 200 FPS on this
>> machine with free drivers.
> No, it will produce about 10,000 FPS with the free nvidia driver (as in
> free from stupidity and incompetence)
We know that you prefer binary drivers. However, others do for different
reasons prefer truly free drivers. Having access to all the sources of all
the software running on your computer means having full control of the
computer. Running a tainted kernel means losing that control.
There are many people that want to encourage the development of free
drivers. One such place is www.free3d.org which has an interesting list of
graphics benchmarks with different cards and truly free drivers.
The inability from nVidia to produce free drivers or to provide
information necessary to produce free drivers probably explain that nVidia
is at the bottom of the list with an FPS no higher than 130.
Anton Ertl
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> Eventually we found out that there is a "-printfps" flag; with the
>> default window size the X800GTO produced about 3650 fps.
>
>Whoha! We have a new top performer. Please report that number with your
>configuration to http://www.free3d.org/
With a little xorg.conf tweaking we got 5400 fps, and I have put that
number there; unfortunately, the tweaks did little for UT2004
performance. In a few days we should also have numbers for the X550
and an X850XT.
Anton Ertl
A freiend of mine just bought a Connect3D Radeon X850XT. It has two
DVI connectors and comes with two DVI-to-VGA adapters. Unfortunately,
Conntect3D was not so generous with my X550, which did not come with
such an adapter. My friend also bought a Palit X850XT AGP card, which
has one DVI and one VGA connector, and comes with one DVI-to-VGA
adapter.
Anton Ertl
>In a few days we should also have numbers for the X550
>and an X850XT.
All right, the glxgears numbers are:
FPS
X550 2888
Palit X800GTO 5424
X850XT 6295
One core of the CPU has 100% utilization with the X850XT, so it is
likely that the graphics card could go faster with a faster CPU (or
a less CPU-hungry driver).
I also ran Unreal Tournament 2004 with the ons-dria demo from
<http://www.nvnews.net/articles/benchmarking/ut2004/>, and got the
following results:
Linux Windows
X550 19fps 39fps
Palit X800GTO 40fps 74fps
X850XT 48fps 75fps
This is in 1280x1024 with most settings on Normal, and all the
checkboxes in the graphics screen enabled except "Coronas" and
"Trilinear".
With the X850XT this benchmark was CPU-bound under Linux (and, judging
from the results, under Windows with the X850XT and the X800GTO).
I also tried varying various X server "Device" Options and found that I get the
best results with
Option "ColorTiling" "on"
Option "EnablePageFlip" "on"
Option "AccelMethod" "XAA"
Only the "EnablePageFlip" is really needed in the Xserver I used (Xorg
7.1.1), the others seem to have these values by default. Setting
"UseVBO=True" in the UT2004.ini is quite important for UT2004 Linux
performance (27fps vs. 40 fps on the X800GTO).
snd...@gmail.com
Anton Ertl wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >In a few days we should also have numbers for the X550
> >and an X850XT.
>
> All right, the glxgears numbers are:
>
> FPS
> X550 2888
> Palit X800GTO 5424
> X850XT 6295
>
> One core of the CPU has 100% utilization with the X850XT, so it is
> likely that the graphics card could go faster with a faster CPU (or
> a less CPU-hungry driver).
>
benchmarking
you can help them by modifying glxgears to make use of both cores to
render alternative
frames or something.
Anton Ertl
>>
>> FPS
>> X550 2888
>> Palit X800GTO 5424
>> X850XT 6295
>>
>> One core of the CPU has 100% utilization with the X850XT, so it is
>> likely that the graphics card could go faster with a faster CPU (or
>> a less CPU-hungry driver).
>>
>Since there is no shortage of perverts who insist on glxgears for
>benchmarking
>you can help them by modifying glxgears to make use of both cores to
>render alternative
>frames or something.
Well, as a poor man's approximation of that I tried running two
glxgears processes (rendering to two windows); the idea was that this
should be less CPU-limited and might achieve a higher combined FPS.
However, what I found was that each process got 2400FPS, i.e., less
than half of the FPS for one process, so the GPU seems to have some
task switching overhead. Three processes got 1600FPS each.
Anton Ertl
In December I wrote here about our experiences with three PCIe Radeon
cards on Debian Etch. Now I have also upgraded an AGP box to Debian
Etch, and tried a number of AGP cards on that: A Radeon 9250 with
128MB, A Radeon 9600 with 128MB, and a Radeon 9600XT with 256MB. The
box is based on a K8V SE Deluxe (VIA K8T800 chipset) with a Socket-754
Athlon 3200+ and 512MB RAM.
Ok, the first experience when I had freshly installed Etch was that
the machine hung when starting X (maybe it was just X hanging, that's
hard to tell when you don't have another machine from which to ssh
into the system under inspection); that happened with the Debian
2.6.17 kernel that came with the installation; note that Debian Etch
has a 2.6.18 kernel in the meantime, and I have not tried that, so the
problem may be fixed in the meantime.
The hanging did not happen with the self-built 2.6.13.2 kernel that I
was using for my old distribution, but I did not get 3D acceleration
with that kernel (hmm, I see that it has CONFIG_DRM=y and
CONFIG_DRM_RADEON=m, so I wonder why that is; maybe I should have just
loaded the appropriate module.
Anyway, I finally used a self-built 2.6.19.2 kernel, resulting in no
hangs and accelerated 3D support.
For the xorg.conf, I used mainly the options I learned from earlier
experiments with the PCIe cards, resulting in the following device
section:
Section "Device"
Identifier "Radeon 9600"
Driver "radeon"
Option "EnablePageFlip" "on"
Option "ColorTiling" "on"
Option "AccelMethod" "on"
Option "AGPMode" "8"
Option "GARTSize" "64"
EndSection
For the Radeon 9250, I also found that setting the environment
variable
export hyperz=true
is very helpful for glxgears performance and a little helpful for
UT2004; this is apparently a special feature of the R200 driver and
does not have any effect on the R300-based cards. I also did
experiments with AGPMode=4, but the difference between the modes on
the 9600 was tiny and appears in favour of AGPMode=4, but that may be
measurement noise (the 9250 results are with AGPMode=4 only; I only
realized too late that the card should support AGPMode=8).
Just for reference, I am also citing numbers from my earlier postings
on PCIe cards:
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>All right, the glxgears numbers are:
>
> FPS
>X550 2888
>Palit X800GTO 5424
>X850XT 6295
9250 128MB 3503 (~2200 without hyperz=true)
9600 128MB 2358
9600XT 256MB 3775
The X550 is a PCIe version of the 9600Pro (i.e., with performance
between the 9600 and the 9600XT), so the results are pretty much as
expected here:
>I also ran Unreal Tournament 2004 with the ons-dria demo from
><http://www.nvnews.net/articles/benchmarking/ut2004/>, and got the
>following results:
>
> Linux Windows
>X550 19fps 39fps
>Palit X800GTO 40fps 74fps
>X850XT 48fps 75fps
>
>This is in 1280x1024 with most settings on Normal, and all the
>checkboxes in the graphics screen enabled except "Coronas" and
>"Trilinear".
Linux
9250 128MB 7.1fps
9600 128MB 7.4fps
9600XT 256MB 18.3fps
The two 128MB cards seem to suffer from a lack of memory, especially
judging from the speed difference between the 9600 and the 9600XT (the
clock rate difference is only a factor of 1.5). The behaviour also
supports this theory: there are long stretches with very low frame
rate (1-2fps), interrupted by spurts where the frame rate rises to
30fps or something; my interpretation is that during the slow parts,
the graphics card gets stuff from main memory into its graphics
memory, and during the fast parts, it runs mostly from graphics
memory. The slow framerate on the 128MB cards could only be slightly
improved by disabling additional features and lowering the resolution
to 800x600; the slow parts remained. Surprisingly, switching from 4x
AGP to 8x AGP had no positive effect. I explain the slightly lower
performance of the 9600xt compared to the x550 with the slower CPU on
the AGP system.
The 128MB 9600 works acceptably in this game under Windows (but I have
noticed similar behaviour from a 64MB card there), so apparently the
free drivers are not very good at managing the graphics card memory,
or at making use of the AGP bus transfers.
Anyway, if you are interested in UT2004 under Linux with free drivers,
better buy a 256MB card; and I guess that holds for some other 3D
games, too. However, planetpenguin-racer runs nicely on the 128MB
9600 (~50fps@1280x1024, ~33fps@1600x1200).
Michael Heiming
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> In December I wrote here about our experiences with three PCIe Radeon
> cards on Debian Etch. Now I have also upgraded an AGP box to Debian
> Etch, and tried a number of AGP cards on that: A Radeon 9250 with
> 128MB, A Radeon 9600 with 128MB, and a Radeon 9600XT with 256MB. The
> box is based on a K8V SE Deluxe (VIA K8T800 chipset) with a Socket-754
> Athlon 3200+ and 512MB RAM.
[..]
>>All right, the glxgears numbers are:
>> FPS
>>X550 2888
>>Palit X800GTO 5424
>>X850XT 6295
> 9250 128MB 3503 (~2200 without hyperz=true)
> 9600 128MB 2358
> 9600XT 256MB 3775
> The X550 is a PCIe version of the 9600Pro (i.e., with performance
> between the 9600 and the 9600XT), so the results are pretty much as
> expected here:
Sounds darn slow to me, iirc get on FC 5 (AMD64 3000, with 6600GT
+ evil nvidia driver somewhere between 10,000-13,000 fps out of
glxgears. But I am by no means expert with 3D graphics cards.
Annoyingly enough, you can't even turn on 3D with XFree86 and
dual head on the box I am typing. Sad enough googleearth remains
dog slow this way. ;(
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 332: suboptimal routing experience
Whoever
On Fri, 2 Feb 2007, Anton Ertl wrote:
>
>
> Linux
> 9250 128MB 7.1fps
> 9600 128MB 7.4fps
> 9600XT 256MB 18.3fps
Something is not right here. I have a Radeon 9200 based AGP card with
128MB and get 1600 FPS (and I have seen over 3000 fps). The Motherboard
is an NFORCE3-based system with Athlon64 3000+
John-Paul Stewart
>
> On Fri, 2 Feb 2007, Anton Ertl wrote:
>
>>
>> Linux
>> 9250 128MB 7.1fps
>> 9600 128MB 7.4fps
>> 9600XT 256MB 18.3fps
>
> Something is not right here. I have a Radeon 9200 based AGP card with
> 128MB and get 1600 FPS (and I have seen over 3000 fps).
Are your figures from the same Unreal Tournament benchmark the OP
mentioned, and at the same resolution (1280x1204)? 1600-3000 fps sounds
more like a synthetic benchmark or perhaps a very low resolution, IMHO.
Whoever
Ah, sorry. Not UT numbers: they were glxgears numbers.
>
>
joseph2k
Indeedy. If you had compared his 9250 numbers of ~2200 and 3503 it would
have saved time all around.
--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.
--Schiller