From: Ian R. <id...@us...> - 2004-10-12 01:37:19
|
I was trying to test the latest version of my ReadPixels work to make sure I didn't break anything on big-endian. However, it seems someone beat me to it in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and then the 3D engine is toast. After that frame is drawn, gears is at 100% and X is unresponsive. When I kill gears, everything goes back to semi-normal. If I run another 3D program, I get an empty (just a frame!) window. Looking at the output from R128_DEBUG=all, it appears to be stuck in r128EmitHwStateLocked. That single frame of gears is also wrong. The colors are pinks and purples. I suspect this may just be a byte-ordering problem. I notice that the driver wants to use BGRA for primary color, but I suspect the hardware really wants ARGB. Ditto for secondary color / fog. |
From: Michel <mi...@da...> - 2004-10-12 04:54:02
|
On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote: > I was trying to test the latest version of my ReadPixels work to make=20 > sure I didn't break anything on big-endian. However, it seems someone=20 > beat me to it in the Rage128 driver. :) In a nutshell, I can get one=20 > frame of gears, and then the 3D engine is toast. After that frame is=20 > drawn, gears is at 100% and X is unresponsive. When I kill gears,=20 > everything goes back to semi-normal. If I run another 3D program, I get=20 > an empty (just a frame!) window. >=20 > Looking at the output from R128_DEBUG=3Dall, it appears to be stuck in=20 > r128EmitHwStateLocked. Please provide a little more context - machine type (G4 I guess? Which model exactly?), AGP/PCI, versions of kernel/DRM/X, ... > That single frame of gears is also wrong. The colors are pinks and=20 > purples. I suspect this may just be a byte-ordering problem. I notice=20 > that the driver wants to use BGRA for primary color, but I suspect the=20 > hardware really wants ARGB. Ditto for secondary color / fog. Yeah, there are endianness issues to work out in t_vertex. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Vladimir D. <vo...@mi...> - 2004-10-12 14:42:14
|
On Mon, 11 Oct 2004, Ian Romanick wrote: > I was trying to test the latest version of my ReadPixels work to make sure I > didn't break anything on big-endian. However, it seems someone beat me to it > in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and > then the 3D engine is toast. After that frame is drawn, gears is at 100% and > X is unresponsive. When I kill gears, everything goes back to semi-normal. > If I run another 3D program, I get an empty (just a frame!) window. > > Looking at the output from R128_DEBUG=all, it appears to be stuck in > r128EmitHwStateLocked. > > That single frame of gears is also wrong. The colors are pinks and purples. > I suspect this may just be a byte-ordering problem. I notice that the driver > wants to use BGRA for primary color, but I suspect the hardware really wants > ARGB. Ditto for secondary color / fog. Just to check off the obvious, are you running a recent kernel with (I assume framebuffer) ? It could be that the default might have changed to configure the apertures to be bigendian. Of course, I have no idea, but this would be one of the "easy" things to check. best Vladimir Dergachev > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Benjamin H. <be...@ke...> - 2004-10-12 23:08:23
|
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > Just to check off the obvious, are you running a recent kernel with (I > assume framebuffer) ? It could be that the default might have changed to > configure the apertures to be bigendian. Changed ? The apertures have always been BE on PPC ... Ben. |
From: Michel <mi...@da...> - 2004-10-13 03:06:32
|
On Wed, 2004-10-13 at 09:07 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: >=20 > > Just to check off the obvious, are you running a recent kernel with (I=20 > > assume framebuffer) ? It could be that the default might have changed t= o=20 > > configure the apertures to be bigendian. >=20 > Changed ? The apertures have always been BE on PPC ... Maybe he meant the MMIO aperture, but again we've always used LE for that. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Vladimir D. <vo...@mi...> - 2004-10-13 14:29:24
|
On Wed, 13 Oct 2004, Benjamin Herrenschmidt wrote: > On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > >> Just to check off the obvious, are you running a recent kernel with (I >> assume framebuffer) ? It could be that the default might have changed to >> configure the apertures to be bigendian. > > Changed ? The apertures have always been BE on PPC ... Really ? Both the register and the framebuffer apertures ? The reason I am asking as ati driver has some code to invert the endianness for writing Xv data to the framebuffer. best Vladimir Dergachev > > Ben. > > |
From: Michel <mi...@da...> - 2004-10-13 16:12:32
|
On Wed, 2004-10-13 at 10:27 -0400, Vladimir Dergachev wrote: >=20 > On Wed, 13 Oct 2004, Benjamin Herrenschmidt wrote: >=20 > > On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > > > >> Just to check off the obvious, are you running a recent kernel with (I > >> assume framebuffer) ? It could be that the default might have changed = to > >> configure the apertures to be bigendian. > > > > Changed ? The apertures have always been BE on PPC ... >=20 > Really ? Both the register and the framebuffer apertures ? No, see my previous post. > The reason I am asking as ati driver has some code to invert the=20 > endianness for writing Xv data to the framebuffer. The r128 and radeon 2D drivers simply change the framebuffer aperture byte-swapping temporarily for this and some other similar things. The 3D drivers basically do everything via the CP. Anyway, I think we're on a tangent here, as the problem doesn't seem to be PPC specific at all. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Ian R. <id...@us...> - 2004-10-13 21:37:37
|
Michel D=C3=A4nzer wrote: > Anyway, I think we're on a tangent here, as the problem doesn't seem to > be PPC specific at all. I dug out the Rage 128 that I have for the PC, and it works just fine.=20 glxgears, readpix, all of it. :( The PCI ID on on the PC version is 1002:5046, and on the Mac it's=20 1002:5246. Could this be a PRO vs. non-PRO issue? Andreas, what's the=20 PCI ID on your card? If this isn't an endian problem, my guess is that=20 there's some hardware bug in the non-PRO version that was fixed in the=20 PRO. It would be like the R200 vs. RV250 texturing bugs. :( |
From: Alex D. <ale...@gm...> - 2004-10-14 03:33:02
|
On Wed, 13 Oct 2004 14:37:12 -0700, Ian Romanick <id...@us...> wrote: > Michel D=E4nzer wrote: >=20 > > Anyway, I think we're on a tangent here, as the problem doesn't seem to > > be PPC specific at all. >=20 > I dug out the Rage 128 that I have for the PC, and it works just fine. > glxgears, readpix, all of it. :( >=20 > The PCI ID on on the PC version is 1002:5046, and on the Mac it's > 1002:5246. Could this be a PRO vs. non-PRO issue? Andreas, what's the > PCI ID on your card? If this isn't an endian problem, my guess is that > there's some hardware bug in the non-PRO version that was fixed in the > PRO. It would be like the R200 vs. RV250 texturing bugs. :( >=20 according to pci.ids: 5046 Rage 128 PF/PRO AGP 4x TMDS 5246 Rage 128 RF/SG AGP So perhaps it is a PRO thing... Alex |
From: Andreas S. <A.S...@gm...> - 2004-10-14 09:12:11
|
Am 2004.10.13 23:37:12 +0200 schrieb(en) Ian Romanick: > Michel D=C3=A4nzer wrote: >=20 > > Anyway, I think we're on a tangent here, as the problem doesn't seem to > > be PPC specific at all. >=20 > I dug out the Rage 128 that I have for the PC, and it works just fine.=20 > glxgears, readpix, all of it. :( >=20 > The PCI ID on on the PC version is 1002:5046, and on the Mac it's=20 > 1002:5246. Could this be a PRO vs. non-PRO issue? Andreas, what's the= =20 > PCI ID on your card? If this isn't an endian problem, my guess is that= =20 > there's some hardware bug in the non-PRO version that was fixed in the=20 > PRO. It would be like the R200 vs. RV250 texturing bugs. :( >=20 The problem (hang/reboot) I see is on Radeon 7500 + mesa-cvs_after_25Sep.2004 + t_vertex-patch PCI-ID of the card I'm currently using: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (rev 0). 01:00.0 Class 0300: 1002:5157 Subsystem: 1002:013a (the other card I have is ATI Technologies Inc Radeon R200 QL [Radeon 8500 = LE]) sorry for the confusion... greetings, Andreas |
From: Andreas S. <A.S...@gm...> - 2004-10-14 12:00:57
Attachments:
mesa_radeon_readpix_spantmp2_edited.diff.txt
|
Am 2004.10.13 23:37:12 +0200 schrieb(en) Ian Romanick: > Michel D=C3=A4nzer wrote: >=20 > > Anyway, I think we're on a tangent here, as the problem doesn't seem to > > be PPC specific at all. >=20 > I dug out the Rage 128 that I have for the PC, and it works just fine.=20 > glxgears, readpix, all of it. :( >=20 > The PCI ID on on the PC version is 1002:5046, and on the Mac it's=20 > 1002:5246. Could this be a PRO vs. non-PRO issue? Andreas, what's the= =20 > PCI ID on your card? If this isn't an endian problem, my guess is that= =20 > there's some hardware bug in the non-PRO version that was fixed in the=20 > PRO. It would be like the R200 vs. RV250 texturing bugs. :( >=20 Hm... some more confusion: 0) I updated my "Mesa_orig" tree. 1) Then translated your readpix changes from r200_span.c to radeon_span.c, and then got the hang with glxgears/readpix. 2) After reboot I "backported" mesa/sources, radeon_span.c etc. to mesa cvs (including tvertex patch) from before 25.Sep.2004 That worked fine, no hang: I got 6.6MPixel/second where the old code showed only 3.5Mpixel/second. My current card: 1002:5157 ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (rev 0). Could someone else with an R100 test? see attached patch ( some changes to make mesa compile with gcc2.95.3 omitt= ed) @Ian: maybe you could try on your "bad" r128 with an older version of mesa. |
From: Ian R. <id...@us...> - 2004-10-15 22:59:42
|
Andreas Stenglein wrote: > Could someone else with an R100 test? > see attached patch ( some changes to make mesa compile with gcc2.95.3 omitted) What were those changes? Were they to avoid the SSE2 code? In any case, your patch looks good to me. In fact, it looks almost identical to one that I'm about to commit to the MGA driver. ;) > @Ian: > maybe you could try on your "bad" r128 with an older version of mesa. I'm going to try this weekend. Fun stuff. :( |
From: Andreas S. <A.S...@gm...> - 2004-10-16 17:22:16
Attachments:
mesa_radeon_readpix_spantmp2_diff.txt
|
Am 2004.10.16 00:59:07 +0200 schrieb(en) Ian Romanick: > Andreas Stenglein wrote: >=20 > > Could someone else with an R100 test? > > see attached patch ( some changes to make mesa compile with gcc2.95.3 o= mitted) >=20 > What were those changes? Were they to avoid the SSE2 code? 1) basically some brackets{} , see attached (complete) patch. 2) no, but sse2 code won't run on my box. Only x86/MMX+/3DNow!+/SSE > In any case, your patch looks good to me. In fact, it looks almost=20 > identical to one that I'm about to commit to the MGA driver. ;) since the old r200 and radeon code was identical, it is identical to your r200 patch, I only changed "r200" -> "radeon" Unfortunately it doesnt work well on my box when applied to mesa-cvs HEAD. > > @Ian: > > maybe you could try on your "bad" r128 with an older version of mesa. >=20 > I'm going to try this weekend. Fun stuff. :( greetings, Andreas |
From: Ian R. <id...@us...> - 2004-10-17 03:15:33
|
Andreas Stenglein wrote: > Am 2004.10.16 00:59:07 +0200 schrieb(en) Ian Romanick: >>Andreas Stenglein wrote: >> >>>Could someone else with an R100 test? >>>see attached patch ( some changes to make mesa compile with gcc2.95.3 omitted) >> >>What were those changes? Were they to avoid the SSE2 code? > > 1) basically some brackets{} , see attached (complete) patch. > 2) no, but sse2 code won't run on my box. Only x86/MMX+/3DNow!+/SSE Okay, those changes make sense. I guess the version of GCC that I'm using allows variables to be declared anywhere (like C++). I was just suspicious that some versions of binutils might support SSE but not SSE2. I can see that's not the case here. >>In any case, your patch looks good to me. In fact, it looks almost >>identical to one that I'm about to commit to the MGA driver. ;) > > since the old r200 and radeon code was identical, > it is identical to your r200 patch, I only changed "r200" -> "radeon" > Unfortunately it doesnt work well on my box when applied to mesa-cvs HEAD. I fixed a couple bugs on Friday that would cause the code to not work in 16-bit mode. Basically, it would try to ues the 8888 SSE / MMX routines even in 16-bit mode. Oops. :) |
From: Benjamin H. <be...@ke...> - 2004-10-13 22:46:41
|
On Thu, 2004-10-14 at 00:27, Vladimir Dergachev wrote: > On Wed, 13 Oct 2004, Benjamin Herrenschmidt wrote: > > > On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > > > >> Just to check off the obvious, are you running a recent kernel with (I > >> assume framebuffer) ? It could be that the default might have changed to > >> configure the apertures to be bigendian. > > > > Changed ? The apertures have always been BE on PPC ... > > Really ? Both the register and the framebuffer apertures ? > > The reason I am asking as ati driver has some code to invert the > endianness for writing Xv data to the framebuffer. No, only framebuffer, and we used, iirc, to switch the card's swapper off when writing Xv data (maybe we just swap the data nowadays ? would be pretty suboptimal...) Ben. |
From: Andreas S. <A.S...@gm...> - 2004-10-12 15:32:11
|
Am 2004.10.12 03:37:05 +0200 schrieb(en) Ian Romanick: > I was trying to test the latest version of my ReadPixels work to make=20 > sure I didn't break anything on big-endian. However, it seems someone=20 > beat me to it in the Rage128 driver. :) In a nutshell, I can get one=20 > frame of gears, and then the 3D engine is toast. After that frame is=20 > drawn, gears is at 100% and X is unresponsive. When I kill gears,=20 > everything goes back to semi-normal. If I run another 3D program, I get= =20 > an empty (just a frame!) window. >=20 > Looking at the output from R128_DEBUG=3Dall, it appears to be stuck in=20 > r128EmitHwStateLocked. >=20 > That single frame of gears is also wrong. The colors are pinks and=20 > purples. I suspect this may just be a byte-ordering problem. I notice= =20 > that the driver wants to use BGRA for primary color, but I suspect the=20 > hardware really wants ARGB. Ditto for secondary color / fog. >=20 >=20 It might be unrelated (and just some other silly mistake/problem): Using my local version of radeon (r100) driver converted to "t_vertex" I discovered a similar problem recently. 1) running glxgears I get the "hang with only mousepointer moving" -> reboo= t needed. 2) setting tcl_mode=3D0 and running glxgears -> instant reboot 3) other software seems to work fine, for example q3 or the projtex test. 4) running glxgears with the "original" driver from mesa-cvs works. I have to check with an older version of mesa and modified radeon driver, b= ut as I recall it did work well somewhen in the past. greetings, Andreas |
From: Ian R. <id...@us...> - 2004-10-12 16:38:43
|
Andreas Stenglein wrote: > It might be unrelated (and just some other silly mistake/problem): > Using my local version of radeon (r100) driver converted to "t_vertex" > I discovered a similar problem recently. > 1) running glxgears I get the "hang with only mousepointer moving" -> reboot needed. I get the hang, but I can ssh in and kill gears. Did you see these problems on x86 or PowerPC? > 2) setting tcl_mode=0 and running glxgears -> instant reboot > 3) other software seems to work fine, for example q3 or the projtex test. > 4) running glxgears with the "original" driver from mesa-cvs works. I got the same hang with progs/demos/readpix. I tested with gears to make sure my changes weren't causing the problem. |
From: Andreas S. <A.S...@gm...> - 2004-10-12 20:46:44
|
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick: > Andreas Stenglein wrote: >=20 > > It might be unrelated (and just some other silly mistake/problem): > > Using my local version of radeon (r100) driver converted to "t_vertex" > > I discovered a similar problem recently. > > 1) running glxgears I get the "hang with only mousepointer moving" -> r= eboot needed. >=20 > I get the hang, but I can ssh in and kill gears. Did you see these=20 > problems on x86 or PowerPC? Its on x86 / Athlon XP with Radeon 7500, gcc 2.95.3 (I added some brackets{} in the dma-templates so it compiles) I can ssh in and kill it, but its not possible to "revive" the box, I have = to switch off. It might work with the soft-reset trick used for debugging r300. > > 2) setting tcl_mode=3D0 and running glxgears -> instant reboot > > 3) other software seems to work fine, for example q3 or the projtex tes= t. > > 4) running glxgears with the "original" driver from mesa-cvs works. >=20 > I got the same hang with progs/demos/readpix. I tested with gears to=20 > make sure my changes weren't causing the problem. Im going to try it (later)... best regards, Andreas |
From: Andreas S. <A.S...@gm...> - 2004-10-13 18:41:43
|
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick: > Andreas Stenglein wrote: >=20 > > It might be unrelated (and just some other silly mistake/problem): > > Using my local version of radeon (r100) driver converted to "t_vertex" > > I discovered a similar problem recently. > > 1) running glxgears I get the "hang with only mousepointer moving" -> r= eboot needed. >=20 > I get the hang, but I can ssh in and kill gears. Did you see these=20 > problems on x86 or PowerPC? >=20 > > 2) setting tcl_mode=3D0 and running glxgears -> instant reboot > > 3) other software seems to work fine, for example q3 or the projtex tes= t. > > 4) running glxgears with the "original" driver from mesa-cvs works. >=20 > I got the same hang with progs/demos/readpix. I tested with gears to=20 > make sure my changes weren't causing the problem. It is unrelated. readpix doesnt make a problem, only gears and glxgears. Mesa CVS up to 25.September 2004 00:00 + t_vertex patch works fine, with gl= xgears, ( cvs -z3 -d:pserver:ano...@pd...:/cvs/mesa update -dA -D = 20040925 Mesa ) Mesa CVS from 26.September 2004 + t_vertex patch and later hangs the machin= e when starting glxgears. ( cvs -z3 -d:pserver:ano...@pd...:/cvs/mesa update -dA -D = 20040926 Mesa ) It looks like glxgears triggers an issue with the new way statechanges are = emitted. greetings, Andreas |
From: Ian R. <id...@us...> - 2004-10-12 15:37:01
|
Michel D=C3=A4nzer wrote: > On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote: >=20 >>I was trying to test the latest version of my ReadPixels work to make=20 >>sure I didn't break anything on big-endian. However, it seems someone=20 >>beat me to it in the Rage128 driver. :) In a nutshell, I can get one=20 >>frame of gears, and then the 3D engine is toast. After that frame is=20 >>drawn, gears is at 100% and X is unresponsive. When I kill gears,=20 >>everything goes back to semi-normal. If I run another 3D program, I ge= t=20 >>an empty (just a frame!) window. >> >>Looking at the output from R128_DEBUG=3Dall, it appears to be stuck in=20 >>r128EmitHwStateLocked. >=20 > Please provide a little more context - machine type (G4 I guess? Which > model exactly?), AGP/PCI, versions of kernel/DRM/X, ... It's a stock AGP G4. The card is the original Rage128. The kernel is=20 the debian 2.6.8-powerpc kernel (dittor for DRM), and X is yesterday's=20 X.org. The last time I did anything with that machine was about a month=20 ago with a 2.4.25 kernel (and whatever X.org was current then), and it=20 worked fine. I suspect the problems are caused by recent changes to the=20 3D driver. Regular X stuff works fine. >>That single frame of gears is also wrong. The colors are pinks and=20 >>purples. I suspect this may just be a byte-ordering problem. I notice= =20 >>that the driver wants to use BGRA for primary color, but I suspect the=20 >>hardware really wants ARGB. Ditto for secondary color / fog. >=20 > Yeah, there are endianness issues to work out in t_vertex. :( If I can get the driver to not wedge, I'll start working on those. |
From: Donnie B. <spy...@ge...> - 2004-10-12 16:54:57
|
On Tue, 2004-10-12 at 08:36, Ian Romanick wrote: > It's a stock AGP G4. The card is the original Rage128. The kernel is > the debian 2.6.8-powerpc kernel (dittor for DRM), and X is yesterday's > X.org. The last time I did anything with that machine was about a month > ago with a 2.4.25 kernel (and whatever X.org was current then), and it > worked fine. I suspect the problems are caused by recent changes to the > 3D driver. > > Regular X stuff works fine. It seems present in xorg 6.8.0 according to https://freedesktop.org/bugzilla/show_bug.cgi?id=1513, so older than that. -- Donnie Berkholz Gentoo Linux |
From: Vladimir D. <vo...@mi...> - 2004-10-13 22:55:13
|
>> >> Really ? Both the register and the framebuffer apertures ? >> >> The reason I am asking as ati driver has some code to invert the >> endianness for writing Xv data to the framebuffer. > > No, only framebuffer, and we used, iirc, to switch the card's swapper > off when writing Xv data (maybe we just swap the data nowadays ? would > be pretty suboptimal...) This is exactly what I was referring to - thank you for the explanation ! One more question - if the aperture is LE and we are writing from BE cpu, where are the constants byte-swapped ? thank you ! Vladimir Dergachev > > Ben. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Michel <mi...@da...> - 2004-10-14 04:07:45
|
On Wed, 2004-10-13 at 18:55 -0400, Vladimir Dergachev wrote: >=20 > One more question - if the aperture is LE and we are writing from BE cpu, > where are the constants byte-swapped ? In the CPU. We use LE load/store instructions. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |