From: Martin S. <Mar...@un...> - 2002-12-12 14:50:46
|
> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time > constraints and stability concerns. [...] I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you chose for XFree86-4.3, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Martin S. <Mar...@un...> - 2002-12-12 22:43:16
|
>> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time >> constraints and stability concerns. [...] > I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you > chose for XFree86-4.3, I'd like to add to my own posting that the branch that you consider for inclusion into XFree86-4.3 definitely looks worse than the Mesa-5.x based stuff - at least from the user perspective. If anyone cares I'll create a few screenshots with FlightGear to lay out the difference I mean, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Michel <mi...@da...> - 2002-12-14 18:02:58
|
On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kerne= l/ > Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >=20 > Log message: > merge changes from trunk since Mesa 5.0 merge Okay, I think that should fix the most pressing issues people think were fixed by the Mesa 5.0 merge. http://penguinppc.org/~daenzer/DRI/mesa-4-0-4-branch.diff is the rest of the trunk changes that applied to the branch; I'd like Brian or Keith to look over the Mesa changes, and I haven't merged the BSD support for vertical blank signals because it doesn't seem to do strict enough checking of the ioctl arguments yet. Strangely, I suddenly see the slowness and stuttering people have been reporting, but it seems to be the same with the drivers and DRM that used to work perfectly, no idea what's up. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: David D. <dawes@XFree86.Org> - 2002-12-16 17:44:28
|
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel D=E4nzer wrote: >On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: >> CVSROOT: /cvsroot/dri >> Module name: xc >> Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/ke= rnel/ >> Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >>=20 >> Log message: >> merge changes from trunk since Mesa 5.0 merge > >Okay, I think that should fix the most pressing issues people think were >fixed by the Mesa 5.0 merge. Thanks for doing that! I've taken that and merged it into the XFree86 trunk. I've also merged the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having much success in committing it. My first commit attempt aborted, then I couldn't connect to the CVS repository for a while, then trying again just now it's failing because there are various locks in the repository from the first aborted attempt. Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can finally finish committing the merge, the post-merge tag will be "mesa-4-0-4-20021215". David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes |
From: David D. <dawes@XFree86.Org> - 2002-12-17 00:37:04
|
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote: >On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel D=E4nzer wrote: >>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: >>> CVSROOT: /cvsroot/dri >>> Module name: xc >>> Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/k= ernel/ >>> Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >>>=20 >>> Log message: >>> merge changes from trunk since Mesa 5.0 merge >> >>Okay, I think that should fix the most pressing issues people think wer= e >>fixed by the Mesa 5.0 merge. > >Thanks for doing that! > >I've taken that and merged it into the XFree86 trunk. I've also merged >the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having much >success in committing it. My first commit attempt aborted, then I >couldn't connect to the CVS repository for a while, then trying again >just now it's failing because there are various locks in the repository >from the first aborted attempt. > >Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can finall= y >finish committing the merge, the post-merge tag will be >"mesa-4-0-4-20021215". The SourceForge admins cleared the locks, and I've finshed committing the merge. The part of this merge that I'm least sure of is the 2D radeon driver. It'd be a big help if someone could take a look at the merged code and let me know of any problems. I've put a diff between those before and after tags at <http://www.xfree86.org/~dawes/mesa404-20021214-15.diff.gz>. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes |
From: Keith W. <ke...@tu...> - 2002-12-17 01:03:06
|
David Dawes wrote: > On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote: >=20 >>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel D=E4nzer wrote: >> >>>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: >>> >>>>CVSROOT: /cvsroot/dri >>>>Module name: xc >>>>Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/k= ernel/ >>>>Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >>>> >>>>Log message: >>>> merge changes from trunk since Mesa 5.0 merge >>> >>>Okay, I think that should fix the most pressing issues people think we= re >>>fixed by the Mesa 5.0 merge. >> >>Thanks for doing that! >> >>I've taken that and merged it into the XFree86 trunk. I've also merged >>the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having much >>success in committing it. My first commit attempt aborted, then I >>couldn't connect to the CVS repository for a while, then trying again >>just now it's failing because there are various locks in the repository >=20 >>from the first aborted attempt. >=20 >>Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can final= ly >>finish committing the merge, the post-merge tag will be >>"mesa-4-0-4-20021215". >=20 >=20 > The SourceForge admins cleared the locks, and I've finshed committing > the merge. The part of this merge that I'm least sure of is the 2D > radeon driver. >=20 > It'd be a big help if someone could take a look at the merged code and > let me know of any problems. I've put a diff between those before and > after tags at <http://www.xfree86.org/~dawes/mesa404-20021214-15.diff.g= z>. First thing I notice is somebody's disabled dri on radeon 9000's (rv250's= ).=20 Added a comment indicating that they didn't know if they were doing the r= ight=20 thing or not, which is kindof dump -- if you don't know, don't make the=20 change. Or ask here, I guess. Also the option to turn off the depth buffer (introduced in the twc work)= has=20 been either knobbled or removed. This may not have been deliberate, hard= to=20 tell. This seems to be the second round of removing this -- or alternatl= y=20 maybe it was only half merged to xfree in the first place. In any case i= t=20 seems to be gone now. I don't know the story behind the removal of RADEONSaveFBDevRegisters() -= -=20 seems to be related to keeping pageflipping working over an fbdev call. = Can=20 anyone comment on whether or not this is still necessary? Keith Keith |
From: David D. <dawes@XFree86.Org> - 2002-12-17 01:54:15
Attachments:
radeon.diff
|
On Tue, Dec 17, 2002 at 01:02:45AM +0000, Keith Whitwell wrote: >David Dawes wrote: >> On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote: >>=20 >>>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel D=E4nzer wrote: >>> >>>>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: >>>> >>>>>CVSROOT: /cvsroot/dri >>>>>Module name: xc >>>>>Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/= kernel/ >>>>>Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >>>>> >>>>>Log message: >>>>> merge changes from trunk since Mesa 5.0 merge >>>> >>>>Okay, I think that should fix the most pressing issues people think w= ere >>>>fixed by the Mesa 5.0 merge. >>> >>>Thanks for doing that! >>> >>>I've taken that and merged it into the XFree86 trunk. I've also merged >>>the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having much >>>success in committing it. My first commit attempt aborted, then I >>>couldn't connect to the CVS repository for a while, then trying again >>>just now it's failing because there are various locks in the repositor= y >>=20 >>>from the first aborted attempt. >>=20 >>>Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can fina= lly >>>finish committing the merge, the post-merge tag will be >>>"mesa-4-0-4-20021215". >>=20 >>=20 >> The SourceForge admins cleared the locks, and I've finshed committing >> the merge. The part of this merge that I'm least sure of is the 2D >> radeon driver. >>=20 >> It'd be a big help if someone could take a look at the merged code and >> let me know of any problems. I've put a diff between those before and >> after tags at <http://www.xfree86.org/~dawes/mesa404-20021214-15.diff.= gz>. > >First thing I notice is somebody's disabled dri on radeon 9000's (rv250'= s).=20 >Added a comment indicating that they didn't know if they were doing the = right=20 >thing or not, which is kindof dump -- if you don't know, don't make the=20 >change. Or ask here, I guess. That looks like a bad merge on my part. There are lots of conflicts between the two versions, and the XFree86 version of this check got through when it shouldn't have. I'll fix it. >Also the option to turn off the depth buffer (introduced in the twc work= ) has=20 >been either knobbled or removed. This may not have been deliberate, har= d to=20 >tell. This seems to be the second round of removing this -- or alternat= ly=20 >maybe it was only half merged to xfree in the first place. In any case = it=20 >seems to be gone now. I don't see an option like that on the DRI trunk either. There's a "NoBackBuffer" option though. >I don't know the story behind the removal of RADEONSaveFBDevRegisters() = --=20 >seems to be related to keeping pageflipping working over an fbdev call. = Can=20 >anyone comment on whether or not this is still necessary? I expect that got accidentally removed. I'm also not sure if the handlin= g of gen_int_cntl is correct everywhere. The attached patch should put back most of what got inadvertently removed. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes |
From: Michel <mi...@da...> - 2002-12-17 02:25:54
|
On Die, 2002-12-17 at 02:53, David Dawes wrote: > >I don't know the story behind the removal of RADEONSaveFBDevRegisters() = --=20 > >seems to be related to keeping pageflipping working over an fbdev call. = Can=20 > >anyone comment on whether or not this is still necessary? >=20 > I expect that got accidentally removed. I'm also not sure if the handlin= g > of gen_int_cntl is correct everywhere. >=20 > The attached patch should put back most of what got inadvertently removed= . Yes, looks good to me, thanks. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Keith W. <ke...@tu...> - 2002-12-17 11:16:44
|
David Dawes wrote: > On Tue, Dec 17, 2002 at 01:02:45AM +0000, Keith Whitwell wrote: >=20 >>David Dawes wrote: >> >>>On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote: >>> >>> >>>>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel D=E4nzer wrote: >>>> >>>> >>>>>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: >>>>> >>>>> >>>>>>CVSROOT: /cvsroot/dri >>>>>>Module name: xc >>>>>>Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm= /kernel/ >>>>>>Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 >>>>>> >>>>>>Log message: >>>>>> merge changes from trunk since Mesa 5.0 merge >>>>> >>>>>Okay, I think that should fix the most pressing issues people think = were >>>>>fixed by the Mesa 5.0 merge. >>>> >>>>Thanks for doing that! >>>> >>>>I've taken that and merged it into the XFree86 trunk. I've also merge= d >>>>the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having muc= h >>>>success in committing it. My first commit attempt aborted, then I >>>>couldn't connect to the CVS repository for a while, then trying again >>>>just now it's failing because there are various locks in the reposito= ry >>> >>>>from the first aborted attempt. >>> >>> >>>>Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can fin= ally >>>>finish committing the merge, the post-merge tag will be >>>>"mesa-4-0-4-20021215". >>> >>> >>>The SourceForge admins cleared the locks, and I've finshed committing >>>the merge. The part of this merge that I'm least sure of is the 2D >>>radeon driver. >>> >>>It'd be a big help if someone could take a look at the merged code and >>>let me know of any problems. I've put a diff between those before and >>>after tags at <http://www.xfree86.org/~dawes/mesa404-20021214-15.diff.= gz>. >> >>First thing I notice is somebody's disabled dri on radeon 9000's (rv250= 's).=20 >>Added a comment indicating that they didn't know if they were doing the= right=20 >>thing or not, which is kindof dump -- if you don't know, don't make the= =20 >>change. Or ask here, I guess. >=20 >=20 > That looks like a bad merge on my part. There are lots of conflicts > between the two versions, and the XFree86 version of this check got > through when it shouldn't have. I'll fix it. OK, no worries. >=20 >>Also the option to turn off the depth buffer (introduced in the twc wor= k) has=20 >>been either knobbled or removed. This may not have been deliberate, ha= rd to=20 >>tell. This seems to be the second round of removing this -- or alterna= tly=20 >>maybe it was only half merged to xfree in the first place. In any case= it=20 >>seems to be gone now. >=20 >=20 > I don't see an option like that on the DRI trunk either. There's a > "NoBackBuffer" option though. Yes, the old brain wasn't working too well last night. What I was concer= ned=20 about was actually Michel's (I think) fix for allocating a depth buffer s= ized=20 to an integral number of tiles (we had a similar problem on the i830).=20 Anyway, it looks like you reinstated this fix too. >=20 >>I don't know the story behind the removal of RADEONSaveFBDevRegisters()= --=20 >>seems to be related to keeping pageflipping working over an fbdev call.= Can=20 >>anyone comment on whether or not this is still necessary? >=20 >=20 > I expect that got accidentally removed. I'm also not sure if the handl= ing > of gen_int_cntl is correct everywhere. >=20 > The attached patch should put back most of what got inadvertently remov= ed. Thanks, David, it looks good to me now. Keith |
From: Linus T. <tor...@tr...> - 2002-12-18 18:04:06
|
Hmm.. I just went back to the CVS head and did the kernel merge part, and had some time to do some testing. The texture problems I've seen in tuxracer, which I _thought_ were fixed by the Mesa-5.0 update are still there on HEAD. Apparently the real fix is on the texmem branch, and the reason I thought it was Mesa-5 is simply because that is where I tested mesa first. In tuxracer, the texture problems show up as a strange "flashing" of textures, which is hard to describe but visually very visible and annoying. I think it has actually gotten worse in HEAD - it used to be mainly the icy patches that flashed, when I just tested it it now was flashing on regular snowy areas too. But maybe that's just my imagination. On the texmem branch, the texture behaviour (well, when I tested it, about two weeks ago, I've been remiss in tracking DRI) was totally solid, at least on tuxracer (which is really the only real 3D program I have). So I don't believe it's a tuxracer bug. Linus |
From: Ingo M. <mi...@el...> - 2002-12-21 14:30:15
|
On Wed, 18 Dec 2002, Linus Torvalds wrote: > In tuxracer, the texture problems show up as a strange "flashing" of > textures, which is hard to describe but visually very visible and > annoying. I think it has actually gotten worse in HEAD - it used to be > mainly the icy patches that flashed, when I just tested it it now was > flashing on regular snowy areas too. But maybe that's just my > imagination. i can see flashing in the Ultima1 demo, it appears to be bad colors, ie. not the objects disappearing but changing color which looks like flashing. The colors almost always go dark and then get restored, on various (and nonrandom) polygon objects in the scene. Ingo |
From: Michel <mi...@da...> - 2002-12-17 01:14:16
|
On Die, 2002-12-17 at 01:36, David Dawes wrote: >=20 > The SourceForge admins cleared the locks, and I've finshed committing > the merge. The part of this merge that I'm least sure of is the 2D > radeon driver. >=20 > It'd be a big help if someone could take a look at the merged code and > let me know of any problems. I've put a diff between those before and > after tags at <http://www.xfree86.org/~dawes/mesa404-20021214-15.diff.gz>= . Indeed, it looks like you reverted some of my fixes to the radeon driver. I'll look into reinstating them tomorrow. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Michel <mi...@da...> - 2002-12-12 15:34:37
|
On Don, 2002-12-12 at 15:29, Martin Spott wrote: > > XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time > > constraints and stability concerns. [...] >=20 > I didn't notice the Mesa-5.x-based stuff is less stable than the stuff yo= u > chose for XFree86-4.3, I'd mostly agree, but I guess the floating point exceptions are showstoppers. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: D. H. <dha...@dr...> - 2002-12-12 17:07:05
|
In all honesty ... I haven't run to any issues with the Mesa 5.x based=20 stuff. Remember - I also take the time to merge the current DRI code bac= k=20 into the the XFree86 CVS repository before I build a release. I picked u= p=20 a copy of Wolfenstein a week or so back just so I could stress test thing= s=20 and so far I have had no issues with it. It works great! As a side note ... the code that I compile is bundled into RPMS based off= =20 of Mike Harris' devel XFree86 RPMS. I am willing to allow other people t= o=20 use them to test code, but .... they need to realize that they shouldn't=20 bug RedHat or Mike Harris about issues they find in them! Since I am the= =20 only one using them, I usually don't change the name of the packager or=20 distributer ... I guess if anyone is really interested in these RPMS I=20 could go back and do that. On Thu, 12 Dec 2002, Michel D=E4nzer wrote: > On Don, 2002-12-12 at 15:29, Martin Spott wrote: > > > XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of t= ime > > > constraints and stability concerns. [...] > >=20 > > I didn't notice the Mesa-5.x-based stuff is less stable than the stuf= f you > > chose for XFree86-4.3, >=20 > I'd mostly agree, but I guess the floating point exceptions are > showstoppers. >=20 >=20 >=20 --=20 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D\\ || D. Hageman <dha...@dr...> || \\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D// |
From: Mike A. H. <mh...@re...> - 2002-12-12 18:04:56
|
On Thu, 12 Dec 2002, D. Hageman wrote: >In all honesty ... I haven't run to any issues with the Mesa 5.x based >stuff. Remember - I also take the time to merge the current DRI code back >into the the XFree86 CVS repository before I build a release. I picked up >a copy of Wolfenstein a week or so back just so I could stress test things >and so far I have had no issues with it. It works great! > >As a side note ... the code that I compile is bundled into RPMS based off >of Mike Harris' devel XFree86 RPMS. I am willing to allow other people to >use them to test code, but .... they need to realize that they shouldn't >bug RedHat or Mike Harris about issues they find in them! Since I am the >only one using them, I usually don't change the name of the packager or >distributer ... I guess if anyone is really interested in these RPMS I >could go back and do that. Distribution: and Packager: fields are filled in by rpm during building, and default to nothing. If you query your rpm packages that you've built, they should show nothing for those 2 fields unless you've customized the rpm configuration to specify something in those fields. Just thought I'd mention that. My CVS XFree86 RPMs are also always avail at the URL in my sig for updating from, or for those who want to use them. HTH -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Brian P. <br...@tu...> - 2002-12-12 18:33:57
|
Michel D=E4nzer wrote: > On Don, 2002-12-12 at 15:29, Martin Spott wrote: >=20 >>>XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time >>>constraints and stability concerns. [...] >> >>I didn't notice the Mesa-5.x-based stuff is less stable than the stuff = you >>chose for XFree86-4.3, >=20 >=20 > I'd mostly agree, but I guess the floating point exceptions are > showstoppers. It's still not clear what the cause of this is. I've heard two possibilities: 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with a command line switch. 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last month. -Brian |
From: Keith W. <ke...@tu...> - 2002-12-12 18:39:34
|
Brian Paul wrote: > Michel D=E4nzer wrote: >=20 >> On Don, 2002-12-12 at 15:29, Martin Spott wrote: >> >>>> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of ti= me >>>> constraints and stability concerns. [...] >>> >>> >>> I didn't notice the Mesa-5.x-based stuff is less stable than the=20 >>> stuff you >>> chose for XFree86-4.3, >> >> >> >> I'd mostly agree, but I guess the floating point exceptions are >> showstoppers. >=20 >=20 > It's still not clear what the cause of this is. I've heard two > possibilities: >=20 > 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with > a command line switch. >=20 > 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow > support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last > month. Neither of these seems to explain what's happening. Keith |
From: Charl P. B. <c.p...@it...> - 2002-12-12 19:12:08
|
On Thu, Dec 12, 2002 at 11:43:03AM -0700, Brian Paul wrote: > Michel Dänzer wrote: > >On Don, 2002-12-12 at 15:29, Martin Spott wrote: > > > >>>XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time > >>>constraints and stability concerns. [...] > >> > >>I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you > >>chose for XFree86-4.3, > > > > > >I'd mostly agree, but I guess the floating point exceptions are > >showstoppers. > > It's still not clear what the cause of this is. I've heard two > possibilities: > > 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with > a command line switch. > > 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow > support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last > month. Neither of these explain the sigfpe that Andreas Stenglein and I have been experiencing. Both of us have been building with gcc 2.95: this eliminates 1. In addition, I have confirmed that I've been running the fixed code: this eliminates 2. See (a.o.) the mail with subject: Re: [Dri-devel] Re: Radeon: lockup on state change Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ |