Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(115) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(143) |
Feb
(177) |
Mar
(390) |
Apr
(285) |
May
(316) |
Jun
(241) |
Jul
(303) |
Aug
(504) |
Sep
(322) |
Oct
(368) |
Nov
(398) |
Dec
(474) |
2001 |
Jan
(734) |
Feb
(712) |
Mar
(736) |
Apr
(358) |
May
(403) |
Jun
(317) |
Jul
(286) |
Aug
(299) |
Sep
(304) |
Oct
(398) |
Nov
(169) |
Dec
(313) |
2002 |
Jan
(406) |
Feb
(506) |
Mar
(520) |
Apr
(629) |
May
(714) |
Jun
(711) |
Jul
(761) |
Aug
(665) |
Sep
(542) |
Oct
(713) |
Nov
(641) |
Dec
(639) |
2003 |
Jan
(468) |
Feb
(748) |
Mar
(781) |
Apr
(812) |
May
(789) |
Jun
(731) |
Jul
(567) |
Aug
(579) |
Sep
(624) |
Oct
(647) |
Nov
(387) |
Dec
(422) |
2004 |
Jan
(592) |
Feb
(630) |
Mar
(514) |
Apr
(457) |
May
(647) |
Jun
(388) |
Jul
(276) |
Aug
(528) |
Sep
(840) |
Oct
(831) |
Nov
(350) |
Dec
(458) |
2005 |
Jan
(584) |
Feb
(654) |
Mar
(706) |
Apr
(229) |
May
(411) |
Jun
(594) |
Jul
(341) |
Aug
(435) |
Sep
(251) |
Oct
(297) |
Nov
(196) |
Dec
(286) |
2006 |
Jan
(295) |
Feb
(378) |
Mar
(300) |
Apr
(204) |
May
(241) |
Jun
(316) |
Jul
(256) |
Aug
(346) |
Sep
(338) |
Oct
(352) |
Nov
(288) |
Dec
(272) |
2007 |
Jan
(194) |
Feb
(242) |
Mar
(329) |
Apr
(357) |
May
(254) |
Jun
(309) |
Jul
(291) |
Aug
(370) |
Sep
(279) |
Oct
(336) |
Nov
(357) |
Dec
(465) |
2008 |
Jan
(396) |
Feb
(370) |
Mar
(407) |
Apr
(350) |
May
(337) |
Jun
(339) |
Jul
(352) |
Aug
(314) |
Sep
(338) |
Oct
(299) |
Nov
(279) |
Dec
(365) |
2009 |
Jan
(596) |
Feb
(601) |
Mar
(588) |
Apr
(542) |
May
(731) |
Jun
(701) |
Jul
(673) |
Aug
(1050) |
Sep
(740) |
Oct
(750) |
Nov
(774) |
Dec
(1044) |
2010 |
Jan
(835) |
Feb
(1215) |
Mar
(1249) |
Apr
(485) |
May
(138) |
Jun
(164) |
Jul
(143) |
Aug
(148) |
Sep
(102) |
Oct
(121) |
Nov
(74) |
Dec
(83) |
2011 |
Jan
(131) |
Feb
(200) |
Mar
(122) |
Apr
(111) |
May
(125) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(6) |
Nov
(1) |
Dec
(4) |
2012 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2013 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(6) |
Nov
(15) |
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(6) |
Feb
(10) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(3) |
2
(2) |
3
|
4
(1) |
5
(10) |
6
(23) |
7
(7) |
8
|
9
(2) |
10
(4) |
11
(9) |
12
(6) |
13
(3) |
14
(17) |
15
(24) |
16
(25) |
17
(16) |
18
(22) |
19
(13) |
20
(12) |
21
(3) |
22
(19) |
23
(10) |
24
(9) |
25
(11) |
26
(9) |
27
(19) |
28
(10) |
29
(1) |
30
(14) |
|
|
|
|
|
|
From: Matthew Cline <matt@ni...> - 2001-09-06 21:26:39
|
On Thursday 06 September 2001 01:23 pm, Michel D=E4nzer wrote: > Leif Delgass wrote: > > I think you need to checkout with "-r X_4_1_0" to get the 4.1.0 relea= se > > tagged tree. > The tag for the 4.1 branch is xf-4_1-branch . I used the DRI project CVS=20 (:pserver:anonymous@...:/cvsroot/dri). It has a X_4_= 1_0=20 label, but no xf_4_1 or DRI branches. I'll try again with the X_4_1_0 br= anch=20 and see how that goes. --=20 Matthew Cline | Suppose you were an idiot. And suppose that matt@... | you were a member of Congress. But I repeat | myself. -- Mark Twain |
From: Leif Delgass <ldelgass@re...> - 2001-09-06 20:51:32
|
On Thu, 6 Sep 2001, Michel D=E4nzer wrote: > Leif Delgass wrote: > > > > On Thu, 6 Sep 2001, Manuel Teira wrote: > > > > > El Jue 06 Sep 2001 06:33, Matthew Cline escribi=F3: > > > > When trying to compile from scratch (make World) using Manuel's M= ach64 > > > > patch that Carl Busjahn sent, make got hung up on the fact that t= here > > > > was no lib/Xau directory. I tried editing the config files so th= at it > > > > would ignore Xau, but no dice. So I gave the "-k" option to make= , and > > > > it compiled most everything without a hitch. But there were stil= l a few > > > > problems: > > > > > > Perhaps you're using a different base. Are you using the 4.1.0 XFre= e CVS > > > trunk as base? > > > I had no problems compiling with the code. Perhaps the XFree 4.1.0 = trunk > > > has changed, is this possible? > > > > I think you need to checkout with "-r X_4_1_0" to get the 4.1.0 relea= se > > tagged tree. > > The tag for the 4.1 branch is xf-4_1-branch . Actually, I'm using the DRI tree (as described in the DRI compilation guide) rather than the xfree86 tree. There doesn't appear to be an 'xf-4_1-branch' tag in the DRI tree. Is there a difference or are these coming from the same repository? From the discussion about trimming the DRI tree, I assumed that the full X tree would contain more than I needed. --Leif Delgass |
From: Michel <michdaen@ii...> - 2001-09-06 20:23:17
|
Leif Delgass wrote: > > On Thu, 6 Sep 2001, Manuel Teira wrote: > > > El Jue 06 Sep 2001 06:33, Matthew Cline escribió: > > > When trying to compile from scratch (make World) using Manuel's Mach64 > > > patch that Carl Busjahn sent, make got hung up on the fact that there > > > was no lib/Xau directory. I tried editing the config files so that it > > > would ignore Xau, but no dice. So I gave the "-k" option to make, and > > > it compiled most everything without a hitch. But there were still a few > > > problems: > > > > Perhaps you're using a different base. Are you using the 4.1.0 XFree CVS > > trunk as base? > > I had no problems compiling with the code. Perhaps the XFree 4.1.0 trunk > > has changed, is this possible? > > I think you need to checkout with "-r X_4_1_0" to get the 4.1.0 release > tagged tree. The tag for the 4.1 branch is xf-4_1-branch . -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
From: Leif Delgass <ldelgass@re...> - 2001-09-06 19:46:07
|
On Thu, 6 Sep 2001, Manuel Teira wrote: > El Jue 06 Sep 2001 06:33, Matthew Cline escribi=F3: > > When trying to compile from scratch (make World) using Manuel's Mach6= 4 > > patch that Carl Busjahn sent, make got hung up on the fact that there= was > > no lib/Xau directory. I tried editing the config files so that it wo= uld > > ignore Xau, but no dice. So I gave the "-k" option to make, and it > > compiled most everything without a hitch. But there were still a few > > problems: > > > > Perhaps you're using a different base. Are you using the 4.1.0 XFree CV= S > trunk as base? > I had no problems compiling with the code. Perhaps the XFree 4.1.0 trun= k has > changed, is this possible? I think you need to checkout with "-r X_4_1_0" to get the 4.1.0 release tagged tree. If you don't specify the tag, you get the current devel trunk. This is what I did and Manuel's patch compiled OK after adding th= e missing Makefile that Manuel posted to the list. --Leif Delgass |
From: Frank Earl <fearl@ai...> - 2001-09-06 19:37:51
|
On Thursday 06 September 2001 13:19, you wrote: > It's nice to see that someone is keeping the fire on. ;-) I just recieved mixed news from the inquiry to ATI- they indicated that unless they're actively working on it they couldn't be of much help where we are. They seemed to think Gareth had this fixed before he went to work for PI/VA, in fact and were confused about our predicament. The devrel contact that replied indicated that he'd be interested in seeing the code we're working with and maybe in their spare time catch something we're missing here. I'm going to tell him that we're in the midst of a re-work to get a new official branch in CVS for the driver and I'll be sending him that work when it's done in a week or so. (Any port in a storm is welcome...) So we will have someone else looking into it with slightly better resources than we do- when and if they find time. -- Frank Earl |
From: Frank Earl <fearl@ai...> - 2001-09-06 19:29:44
|
On Thursday 06 September 2001 14:18, James Jones wrote: > God knows this sounds good to me. Wonder what kind of speed penalty > this will incur. From past history of the Utah-GLX drivers for this chip, bus-mastering makes this chip about 40-50% faster than the direct register calls with the buffer insertion loop. > Would you like to divide up the work? I don't want to start doing this > and then have submit a patch with the exact same code I just wrote 1 day > before I finish. I've got time to work on this, so I'll be helping your > progress, not impeding it by lagging, send me a mail if you like. Let me think about that- I'm at work right now and can't look at the stuff I have been working with or Manuel's latest. At the minimum, we're going to need someone that understands kernel modules and can code the psuedo-bus-master loop into the DRM, using the Utah-GLX code for the same as a crib sheet. We're also going to need someone with the tech specs in hand to come up with the acceleration code for Mesa, etc. I'll need to look at things, because I'm pretty sure I could divide it up a little finer than that for people if they want in on the work. -- Frank Earl |
From: Nick Hudson <nhudson@hi...> - 2001-09-06 18:43:33
|
9/6/2001 8:59:40 AM, Nick Hudson <nhudson@...> wrote: Ok I got home and ran X with only a xtem in twm and I still getthe jitterness as I did before. I made sure nothing was being written to X when I started it. As I said I run E so I had to turn off fam and efsd and I rebooted to make sure it was clean. Then I ran quake3 and it was still fine one moment then very slow the next back and forth like 60-70 fps one second then maybe 5-10 the next and it just back and forth all the time. So any other ideas?? Thanks Nick >9/6/2001 7:07:00 AM, Ronald de Man <deman@...> wrote: > >>On Thu, Sep 06, 2001 at 12:29:16AM -0500, Nick Hudson wrote: >>> Greetings, >>> >>> I got DRI and Glide Installed without a hitch on RH 7.1 witha V3 >>> 3000 and now when I run either full screen or windowed game of Q3A it >>> will run smooth and then jump down to 1-2 fps then jump back up. At 1st >>> I thought it was due to just a heavy load but then I tryed it on a level >>> with just myself and it did the smae thing again. It seems like fps is >>> jumping backand forth. Any ideas on what I can do to solve this? >> >>This could be a window manager or desktop applet writing to your >>screen at regular intervals. Don't run Enlightenment... :) >> > >Well ok that could be the problem then. I run Enlightenment as my window manager so ill try using blackbox or >something lite to run the games in just to see what diffrent effect I get. > >Thanks >Nick Hudson > > >>You could try to start X with just one xterm and no window manager. >>Then start q3a from that xterm, adding ">&/dev/null" to the command line >>to prevent any interference with the 2d part of X. >> >>Also make sure no other tasks are consuming cpu cycles. >> >>Ronald de Man >> >> >>_______________________________________________ >>Dri-devel mailing list >>Dri-devel@... >>https://lists.sourceforge.net/lists/listinfo/dri-devel >> >> > > |
From: Manuel Teira <manuel.teira@so...> - 2001-09-06 18:39:16
|
El Jue 06 Sep 2001 20:18, James Jones escribi=F3: > Frank Earl wrote > > >Gang, if it's okay with you all, I'm for largely suspending worrying = about > >bus-mastering right at the moment and worry about having some sort of > >framework in place that uses the bus-mastering buffers to push the da= ta > >to the engine. We know that the draw engine works correctly from the= DRM > >module- so let's use that to create the illusion of a bus-mastering p= ass > > just like Utah-GLX offers with the "psuedo-DMA" mode. This way we c= an > > get something in CVS that will be properly useful for people for at = least > > some apps while we struggle with getting the last drops of speed out= of > > this chip. > > God knows this sounds good to me. Wonder what kind of speed penalty > this will incur. I think this is the best thing. We NEED a CVS branch for the mach64 ASAP= . My poor patch is getting old very quick. |
From: Manuel Teira <manuel.teira@so...> - 2001-09-06 18:34:14
|
El Jue 06 Sep 2001 06:33, Matthew Cline escribi=F3: > When trying to compile from scratch (make World) using Manuel's Mach64 > patch that Carl Busjahn sent, make got hung up on the fact that there = was > no lib/Xau directory. I tried editing the config files so that it wou= ld > ignore Xau, but no dice. So I gave the "-k" option to make, and it > compiled most everything without a hitch. But there were still a few > problems: > Perhaps you're using a different base. Are you using the 4.1.0 XFree CVS= trunk as base? I had no problems compiling with the code. Perhaps the XFree 4.1.0 trunk= has changed, is this possible? Best regards. |
From: James Jones <out@so...> - 2001-09-06 18:20:01
|
Frank Earl wrote >Gang, if it's okay with you all, I'm for largely suspending worrying about >bus-mastering right at the moment and worry about having some sort of >framework in place that uses the bus-mastering buffers to push the data >to the engine. We know that the draw engine works correctly from the DRM >module- so let's use that to create the illusion of a bus-mastering pass just >like Utah-GLX offers with the "psuedo-DMA" mode. This way we can get >something in CVS that will be properly useful for people for at least some >apps while we struggle with getting the last drops of speed out of this chip. > God knows this sounds good to me. Wonder what kind of speed penalty this will incur. Would you like to divide up the work? I don't want to start doing this and then have submit a patch with the exact same code I just wrote 1 day before I finish. I've got time to work on this, so I'll be helping your progress, not impeding it by lagging, send me a mail if you like. -James |
From: Manuel Teira <manuel.teira@so...> - 2001-09-06 17:20:54
|
El Jue 06 Sep 2001 14:28, Frank Earl escribi=F3: > On Wednesday 05 September 2001 22:32, Daryll Strauss wrote: > > I'd suggest the dri-devel mailing list, that way everyone can see wh= at's > > going on. If there's lots of traffic we can easily create a dri-mach= 64 > > list. But for now, I'd encourage people to post progress here. > > I'll second the motion. So far, we're not up to speed enough to merit= our > own little list (Bus-mastering is still eluding us...) but some sort o= f > reference for all of us on the site might be nice. > > As for status, I've sent in a request for more information to ATI- the > documentation's a little thin in a few areas (i.e. Host error interrup= t > values and how to respond to them, what might hang the bus-mastering e= ngine > and how to unhang it without having to power-cycle the chip). I'm hop= ing > for a reply from them in another couple of days. While I'm waiting fo= r > that, I've been looking through the ati XFree86 driver init code but I= 've > not yet found anything obvious that would be causing the problems we'r= e > having. It's nice to see that someone is keeping the fire on. ;-) Best regards. -- M. Teira |
From: Manuel Teira <manuel.teira@so...> - 2001-09-06 17:16:39
|
El Jue 06 Sep 2001 03:48, Frank Worsley escribi=F3: > Hi all, > > it seems we have a pretty sizeable group of people who are working on = the > Mach64 driver. Perhaps would be more accurate saying: "group of people who want to work= on...". I'm not sure, but haven't heard about progress lately in the dri= ver. I send my patch for the 4.1.0 trunk to some people requesting it, but I'= ve never heard again about most of them. > > Should I set up a page on the DRI website with a list of names and ema= il > addresses so that you guys can stay in touch more easily? Or do you wa= nt to > handle all communication through the list? I think that all the communication can be handled by the DRI list. There= 's actually very few communication just now. We have a great jam with the D= MA bug, and we have no solution yet. > > If yes, then anybody who would like to be listed on the page should se= nd me > an email. Thanks. > > - Frank > > > _______________________________________________ > Dri-devel mailing list > Dri-devel@... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Nicholas Charles Leippe <ncl3@em...> - 2001-09-06 17:07:29
|
> Alexander Stohr wrote: > > > > > Now, why would 16bpp get a whopping %50 higher fps in gears than > > > 24/32bpp? > > > > > > 16bpp: ~1300fps > > > 24bpp: ~900fps > > > > > > Is this showing what I think it is--a perfect example of being > > > through-put bound (50% more bytes to push)? > > > > 2 bytes/pixel * 1300 fps = 2600 bytes/s * frames/pixel > > 3 bytes/pixel * 900 fps = 2700 bytes/s * frames/pixel > > > > I have to assume that your image is fill rate limited, > > because the transfer rate values are rather equal. > > Except depth 24 is 32 bpp, so it's > > 4 bytes/pixel * 900 fps = 3600 bytes/s * frames/pixel > > Probably 16 bit is CPU bound and 32 bit fillrate bound? Hrm, so how could I test this? If 16bpp is cpu bound and not fillrate bound, then if I full-screened the app it should get the same fps, right? (assuming it hasn't by then hit a fill-rate bound) And if 32bpp is fill-rate bound, full-screening the app should cause the fps to go down. Would this be reasonable? (can't try it till I get home though) Nick > > > PS: Who set the the list up to set the Reply To: header to the list address? > It's considered harmful. > |
From: Michel <michdaen@ii...> - 2001-09-06 16:47:34
|
Alexander Stohr wrote: > > > Now, why would 16bpp get a whopping %50 higher fps in gears than > > 24/32bpp? > > > > 16bpp: ~1300fps > > 24bpp: ~900fps > > > > Is this showing what I think it is--a perfect example of being > > through-put bound (50% more bytes to push)? > > 2 bytes/pixel * 1300 fps = 2600 bytes/s * frames/pixel > 3 bytes/pixel * 900 fps = 2700 bytes/s * frames/pixel > > I have to assume that your image is fill rate limited, > because the transfer rate values are rather equal. Except depth 24 is 32 bpp, so it's 4 bytes/pixel * 900 fps = 3600 bytes/s * frames/pixel Probably 16 bit is CPU bound and 32 bit fillrate bound? PS: Who set the the list up to set the Reply To: header to the list address? It's considered harmful. -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
From: <pasik@ik...> - 2001-09-06 15:10:42
|
On Thu, 6 Sep 2001, Frank Earl wrote: > On Wednesday 05 September 2001 22:32, Daryll Strauss wrote: > > > I'd suggest the dri-devel mailing list, that way everyone can see what'= s > > going on. If there's lots of traffic we can easily create a dri-mach64 > > list. But for now, I'd encourage people to post progress here. > > I'll second the motion. So far, we're not up to speed enough to merit ou= r > own little list (Bus-mastering is still eluding us...) but some sort of > reference for all of us on the site might be nice. > > As for status, I've sent in a request for more information to ATI- the > documentation's a little thin in a few areas (i.e. Host error interrupt > values and how to respond to them, what might hang the bus-mastering engi= ne > and how to unhang it without having to power-cycle the chip). I'm hoping= for > a reply from them in another couple of days. While I'm waiting for that, > I've been looking through the ati XFree86 driver init code but I've not y= et > found anything obvious that would be causing the problems we're having. > Where can I get the newest mach64-patch (against 4.1.0 or dri-trunk) ? Thanks. - Pasi K=E4rkk=E4inen ^ . . Linux / - \ Choice.of.the .Next.Generation. |
From: Nick Hudson <nhudson@hi...> - 2001-09-06 14:00:18
|
9/6/2001 7:07:00 AM, Ronald de Man <deman@...> wrote: >On Thu, Sep 06, 2001 at 12:29:16AM -0500, Nick Hudson wrote: >> Greetings, >> >> I got DRI and Glide Installed without a hitch on RH 7.1 witha V3 >> 3000 and now when I run either full screen or windowed game of Q3A it >> will run smooth and then jump down to 1-2 fps then jump back up. At 1st >> I thought it was due to just a heavy load but then I tryed it on a level >> with just myself and it did the smae thing again. It seems like fps is >> jumping backand forth. Any ideas on what I can do to solve this? > >This could be a window manager or desktop applet writing to your >screen at regular intervals. Don't run Enlightenment... :) > Well ok that could be the problem then. I run Enlightenment as my window manager so ill try using blackbox or something lite to run the games in just to see what diffrent effect I get. Thanks Nick Hudson >You could try to start X with just one xterm and no window manager. >Then start q3a from that xterm, adding ">&/dev/null" to the command line >to prevent any interference with the 2d part of X. > >Also make sure no other tasks are consuming cpu cycles. > >Ronald de Man > > >_______________________________________________ >Dri-devel mailing list >Dri-devel@... >https://lists.sourceforge.net/lists/listinfo/dri-devel > > |
From: Frank Earl <fearl@ai...> - 2001-09-06 13:44:08
|
On Thursday 06 September 2001 00:33, Matthew Cline wrote: > As far as I can tell I set up everything properly, and I have no clue as to > why all this is happenning. > > Any help would be appreciated. Version drift is the source of your woes... Someone's going to need to pull the patch bundle up to date again. Gang, if it's okay with you all, I'm for largely suspending worrying about bus-mastering right at the moment and worry about having some sort of framework in place that uses the bus-mastering buffers to push the data to the engine. We know that the draw engine works correctly from the DRM module- so let's use that to create the illusion of a bus-mastering pass just like Utah-GLX offers with the "psuedo-DMA" mode. This way we can get something in CVS that will be properly useful for people for at least some apps while we struggle with getting the last drops of speed out of this chip. -- Frank Earl |
From: Frank Earl <fearl@ai...> - 2001-09-06 13:29:46
|
On Wednesday 05 September 2001 22:32, Daryll Strauss wrote: > I'd suggest the dri-devel mailing list, that way everyone can see what's > going on. If there's lots of traffic we can easily create a dri-mach64 > list. But for now, I'd encourage people to post progress here. I'll second the motion. So far, we're not up to speed enough to merit our own little list (Bus-mastering is still eluding us...) but some sort of reference for all of us on the site might be nice. As for status, I've sent in a request for more information to ATI- the documentation's a little thin in a few areas (i.e. Host error interrupt values and how to respond to them, what might hang the bus-mastering engine and how to unhang it without having to power-cycle the chip). I'm hoping for a reply from them in another couple of days. While I'm waiting for that, I've been looking through the ati XFree86 driver init code but I've not yet found anything obvious that would be causing the problems we're having. -- Frank Earl |
From: Ronald de Man <deman@wi...> - 2001-09-06 11:58:13
|
On Thu, Sep 06, 2001 at 12:29:16AM -0500, Nick Hudson wrote: > Greetings, > > I got DRI and Glide Installed without a hitch on RH 7.1 witha V3 > 3000 and now when I run either full screen or windowed game of Q3A it > will run smooth and then jump down to 1-2 fps then jump back up. At 1st > I thought it was due to just a heavy load but then I tryed it on a level > with just myself and it did the smae thing again. It seems like fps is > jumping backand forth. Any ideas on what I can do to solve this? This could be a window manager or desktop applet writing to your screen at regular intervals. Don't run Enlightenment... :) You could try to start X with just one xterm and no window manager. Then start q3a from that xterm, adding ">&/dev/null" to the command line to prevent any interference with the 2d part of X. Also make sure no other tasks are consuming cpu cycles. Ronald de Man |
From: Nick Hudson <nhudson@hi...> - 2001-09-06 05:30:21
|
Greetings, I got DRI and Glide Installed without a hitch on RH 7.1 witha V3 3000 and now when I run either full screen or windowed game of Q3A it will run smooth and then jump down to 1-2 fps then jump back up. At 1st I thought it was due to just a heavy load but then I tryed it on a level with just myself and it did the smae thing again. It seems like fps is jumping backand forth. Any ideas on what I can do to solve this? Thanks Nick Hudson |
From: Matthew Cline <matt@ni...> - 2001-09-06 04:34:34
|
When trying to compile from scratch (make World) using Manuel's Mach64 pa= tch=20 that Carl Busjahn sent, make got hung up on the fact that there was no=20 lib/Xau directory. I tried editing the config files so that it would ign= ore=20 Xau, but no dice. So I gave the "-k" option to make, and it compiled mos= t=20 everything without a hitch. But there were still a few problems: xkbout.c:57:32: extensions/XKBfile.h: No such file or directory aticonfig.c: In function `ATIProcessOptions': aticonfig.c:168: structure has no member named `OptionBlend' atidga.c: In function `ATIDGABlitTransRect': atidga.c:250: structure has no member named `XAAForceTransBlit' atidga.c:255: structure has no member named `XAAForceTransBlit' atidga.c: In function `ATIDGAInit': atidga.c:412: structure has no member named `ATIDGAFunctions' atimach64.c:839: conflicting types for `ATIMach64SetDPMSMode' atimach64.h:44: previous declaration of `ATIMach64SetDPMSMode' atimode.c: In function `ATIModeCalculate': atimode.c:738: structure has no member named `OptionBlend' atimode.c:775: structure has no member named `OptionBlend' As far as I can tell I set up everything properly, and I have no clue as = to=20 why all this is happenning. Any help would be appreciated. --=20 Matthew Cline | Suppose you were an idiot. And suppose that matt@... | you were a member of Congress. But I repeat | myself. -- Mark Twain |
From: Daryll Strauss <daryll@da...> - 2001-09-06 02:32:47
|
On Wed, Sep 05, 2001 at 06:48:06PM -0700, Frank Worsley wrote: > it seems we have a pretty sizeable group of people who are working on the > Mach64 driver. > > Should I set up a page on the DRI website with a list of names and email > addresses so that you guys can stay in touch more easily? Or do you want to > handle all communication through the list? > > If yes, then anybody who would like to be listed on the page should send me > an email. Thanks. I'd suggest the dri-devel mailing list, that way everyone can see what's going on. If there's lots of traffic we can easily create a dri-mach64 list. But for now, I'd encourage people to post progress here. - |Daryll |
From: Frank Worsley <fworsley@ho...> - 2001-09-06 01:52:02
|
Hi all, it seems we have a pretty sizeable group of people who are working on the Mach64 driver. Should I set up a page on the DRI website with a list of names and email addresses so that you guys can stay in touch more easily? Or do you want to handle all communication through the list? If yes, then anybody who would like to be listed on the page should send me an email. Thanks. - Frank |