This is my third attempt sending this email. If sourceforge decides to let
all three copies through at once, you'll have to forgive me.
A while back it was suggested that benchmarking all of the various
DRI-compatible video cards might provide some interesting information. I
just finished my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 22 August 2004 02:16, John Lightsey wrote:
At any rate, here are the results of the first run. If anyone has
suggestions for fixing any of the cards which failed in one way or
another, I would really appreciate the feedback.
Awesome
Diamond Speedstar a90 16MB (savage 4 pro+) Lots of
lockups.
I can confirm that this card locks up very frequently.
One way which I have found to immediately lock it up
is by attempting to use GL_NV_texgen_reflection.
Hope this helps the savage developers.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1003
--- Additional Comments From [EMAIL PROTECTED] 2004-08-22 01:23 ---
Could you
On Sat, 21 Aug 2004 23:44:26 -0500
Steven J. Hill [EMAIL PROTECTED] wrote:
Latest CVS checkout does not compile, please apply.
-Steve
Please note that the xc module in DRI CVS has been officially declared
dead. All DRI development is now going on in either Mesa CVS or Xorg
CVS. Only the DRM
On Sunday 22 August 2004 08:16, John Lightsey wrote:
Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768
it usually froze. glxgears gave this one 518.6 fps.
I also encountered this instability on a mobility M6 (mobile Rage128)
On Sun, 22 Aug 2004 01:16:18 -0500
John Lightsey [EMAIL PROTECTED] wrote:
Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave
this a disappointing 229 fps.
There are rumors about some Savage4's that lock up when reading the
status register. :-/ A workaround would be
On 22.08.2004, at 08:16, John Lightsey wrote:
glxgears - let it run for 1 minute then marked down the highest score
how reproducable and meaningful is a highest score? I don't know, but I
got a feeling that using a mean or a median might be of better
reproducability and also might better reflect
On Sunday 22 August 2004 04:57, Simon 'corecode' Schubert wrote:
On 22.08.2004, at 08:16, John Lightsey wrote:
glxgears - let it run for 1 minute then marked down the highest score
how reproducable and meaningful is a highest score? I don't know, but I
got a feeling that using a mean or a
On Sunday 22 August 2004 04:59, Felix Kühling wrote:
On Sun, 22 Aug 2004 01:16:18 -0500
John Lightsey [EMAIL PROTECTED] wrote:
Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears
gave this a disappointing 229 fps.
There are rumors about some Savage4's that lock up when
On Sul, 2004-08-22 at 02:51, Jon Smirl wrote:
Michel pointed out that all IOCTL calls hold the big kernel lock.
Releasing this lock is sure to case problems since the DRM code is not
designed to be reentrant.
That lock is already released whenever the code sleeps (eg page faults)
so if its
On Sul, 2004-08-22 at 07:16, John Lightsey wrote:
I shut off most of the services on the machine. rcconf shows klogd, makedev,
and sysklogd as the only services active at boot. The kernel used was
2.6.7-1-k7 from Debian.
Which DRI kernel modules - the CVS tree provided ones or the 2.6.7
Which DRI kernel modules - the CVS tree provided ones or the 2.6.7
kernel ones ?
there should be no regression between them, I'd expect the currrnt CVS
ones might in theory be slower than 2.6.7 but I haven't seen any
regressions on the radeon modules while I've been doing the function table
On Sul, 2004-08-22 at 13:11, Dave Airlie wrote:
there should be no regression between them, I'd expect the currrnt CVS
ones might in theory be slower than 2.6.7 but I haven't seen any
regressions on the radeon modules while I've been doing the function table
work, 2.6.7 is pretty close to CVS
A while back it was suggested that benchmarking all of the various
DRI-compatible video cards might provide some interesting information. I
just finished my first attempt at performing a slew of benchmarks with this
goal, and the results haven't been great. It's certainly possible that (a)
On Sat, 2004-08-21 at 15:25, Fernando Pablo Lopez-Lezcano wrote:
On Fri, 2004-08-20 at 22:59, Jon Smirl wrote:
I don't believe the DRM drivers are holding any global kernel locks
when they do wait_for_fifo. Any locks held would be internal to DRM and
can be changed if needed.
There must
On Sunday 22 August 2004 01:52, Adam Jackson wrote:
On Sunday 22 August 2004 02:16, John Lightsey wrote:
At any rate, here are the results of the first run. If anyone has
suggestions for fixing any of the cards which failed in one way or
another, I would really appreciate the feedback.
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
memory somewhere. I would think the
[please cc me, I'm not on the dri list]
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
On Fri, 2004-08-20 at 22:59, Jon Smirl wrote:
I don't believe the DRM drivers are holding any global kernel locks
when they do wait_for_fifo. Any locks held would be internal to DRM and
can be changed if needed.
There must be a lock. I used to use a patch that I found somewhere (that
does
On Sat, 2004-08-21 at 09:58, Jon Smirl wrote:
BTW, loops like this are in most of the DRM drivers for other cards.
They are probably in accelerated framebuffer drivers too.
I know for a fact that the mga driver also has this problem, and I
suspect that the r128 is also affected (but have not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I sent this message earlier, but it doesn't seem to have made it through.
Subject: First DRI uber-benchmark
Date: Saturday 21 August 2004 13:17
From: John Lightsey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
A while back it was suggested that
* Jon Smirl [EMAIL PROTECTED] wrote:
--- Ingo Molnar [EMAIL PROTECTED] wrote:
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then you can sleep precisely up to completion:
On Sun, 2004-08-22 at 11:40 +0200, Steffen Hein wrote:
On Sunday 22 August 2004 08:16, John Lightsey wrote:
Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768
it usually froze. glxgears gave this one 518.6 fps.
I also encountered this instability on a mobility M6
On Sun, 2004-08-22 at 01:16 -0500, John Lightsey wrote:
This is my third attempt sending this email. If sourceforge decides to let
all three copies through at once, you'll have to forgive me.
It's mostly me administrating the dri-{announce,devel,patches} at the
moment... if anyone (preferably
On Sunday 22 August 2004 05:39, Alan Cox wrote:
On Sul, 2004-08-22 at 07:16, John Lightsey wrote:
I shut off most of the services on the machine. rcconf shows klogd,
makedev, and sysklogd as the only services active at boot. The kernel
used was 2.6.7-1-k7 from Debian.
Which DRI kernel
You're right. It's a 8mb mobility M3 in a dell latitude c600.
Sorry, not my notebook ;-)
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off
Here are the FGLRX and Nvidia scores for comparison...
The Nvidia drivers were built from the packages in Debian non-free (1.0.6111)
and the FGLRX drivers were built from Flavio Stanchina's packages (3.11.1).
BFG FX5200 Ultra 128MB
glxgears - 3934.8
q2 640x480 - 337.1
q2 800x600 - 312.3
q2
In gmane.comp.video.dri.devel, you wrote:
I looked around for some free software programs that would calculate an
average framerate rather than simply showing a FPS counter, but I didn't find
any. Something based on crystal-space would be particularly nice.
Have a look at the samples
On Sul, 2004-08-22 at 21:51, John Lightsey wrote:
So... A Radeon DDR 32MB running DRI seems to be faster than a TNT2 32MB.
Matrox G400 seems to be faster on everything other than Unreal Tournament.
I'll send a link to the graphs on Monday.
Maybe I should get the Voodoo2 DRI written. The
On Fri, 2004-08-20 at 22:37, Dave Airlie wrote:
It looks like the timeout for many Radeon DRI operations is controlled
by the dev_priv-usec_timeout value, which is copied from userspace via
ioctl in radeon_cp_init. This value can be as large as 100 MSECS!
radeon_drv.h:#define
At least on the fedora-test list the new Xorg CVS seems to be showing up
some i815/830 works with 2.6.8.1 but not 2.6.old kernels.
hmm interesting.. I'll try and get Xorg on one of my i810 systems in the
next day or two...
Dave.
--
David Airlie, Software Engineer
On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote:
Matrox G400 32MB (mga)
glxgears - 1000.2
q2 640x480 - 62.9
q2 800x600 - 52.3
q2 1024x768 - 40.2
q3 640x480 - 65.9
q3 800x600 - 51.4
q3 1024x768 - 36.4
rtcw 640x480 - 42.3
rtcw 800x600 - 33.5
rtcw 1024x768 - 24.7
ut
On Sunday 22 August 2004 18:37, Ville Syrjälä wrote:
On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote:
Matrox G400 32MB (mga)
...
I'm aware of two perfomance bottlenecks in the driver.
Number one is that it always uses synchronous DMA. I have asynchronous
DMA working just fine
--- Jon Smirl [EMAIL PROTECTED] wrote:
Michel pointed out that all IOCTL calls hold the big kernel lock.
Releasing this lock is sure to case problems since the DRM code is not
designed to be reentrant. I don't know what it will take to fix locking
to allow this, maybe one of the original DRM
--- Ingo Molnar [EMAIL PROTECTED] wrote:
* Jon Smirl [EMAIL PROTECTED] wrote:
--- Ingo Molnar [EMAIL PROTECTED] wrote:
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then
36 matches
Mail list logo
