--- 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 ha
--- 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 origina
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
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
>
> 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
http://www.skynet.ie
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
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. Th
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 prov
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 1024x
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 R
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
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 (preferabl
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 mobil
* 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:
-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 benchmar
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 t
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 co
[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: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 qu
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 feedbac
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.
>
> The
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)
so
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 C
>
> 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 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
ke
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 b
On Sad, 2004-08-21 at 16:00, Michel DÃnzer wrote:
> On Fri, 2004-08-20 at 22:59 -0700, 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.
>
> Keep in mind
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 loc
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
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 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
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 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 th
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 t
34 matches
Mail list logo
