From: <jm...@ne...> - 2003-07-18 11:46:04
|
[ Please CC me on reply, I'm not subscribed ] Hi, I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) with a 20030504 snapshot of DRI (xlibmesa-gl1) and I experienced glitches. I tried a 20030425 snapshot which worked fine (but much slower IMO) so I guess something broke in between. Has anyone heard of it? Has this been already fixed? TIA. Cheers, -- J=E9r=F4me Marant |
From: Paul Z. <pe...@tr...> - 2003-07-18 16:27:17
|
jm...@ne... wrote: >[ Please CC me on reply, I'm not subscribed ] > > Hi, > > I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) > with a 20030504 snapshot of DRI (xlibmesa-gl1) and I experienced > glitches. I tried a 20030425 snapshot which worked fine (but much > slower IMO) so I guess something broke in between. > > By "glitches" do you mean texture flickering and the like? For example, when you jump the sardine outline flickers. I've seen something on x86. I mention it because I don't see a Bug. Maybe they are related and a Bug needs to be opened. If you set the environment variable R200_NO_TCL to 1 it would go away because it's using the software TCL. Maybe the old snapshot was using software TCL? Other symptoms: bzflag - fire a shot and the walls flicker like it's World War 3 Neverwinter Nights - "terminator syndrome" (characters all look like the T-1000 shifting if Env. mapping is enabled) I have a Radeon 8500LE (R200) on a VIA chipset board with an Athlon XP 1800+ (1.5ghz). Using gentoo with ACCEPT_KEYWORDS="~x86". I've also noticed that it looks like the "full screen" GL window for screen savers is off by 1 pixel. There is pixel garbage around the bottom and right sides of the screen if I use the OpenGL screen savers. My apologies if these problems are already fixed in the CVS, I haven't had time to experiment with downloading/compiling DRI out of CVS yet. Paul |
From: <jm...@ne...> - 2003-07-19 08:51:48
|
[ Please CC me on reply, I'm not subscribed ] Paul Zaremba <pe...@tr...> writes: > jm...@ne... wrote: >> >> I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) >> with a 20030504 snapshot of DRI (xlibmesa-gl1) and I experienced >> glitches. I tried a 20030425 snapshot which worked fine (but much >> slower IMO) so I guess something broke in between. >> > By "glitches" do you mean texture flickering and the like? > For example, when you jump the sardine outline flickers. Yes, like that. And fishes appear as rectangles, as well as trees. > I've seen something on x86. I mention it because I don't see a Bug. > Maybe they are related and a Bug needs to be opened. > > If you set the environment variable R200_NO_TCL to 1 it would go away > because it's using the software TCL. Maybe the old snapshot was using > software TCL? I don't know. This thread where I investigated may give hints: http://lists.debian.org/debian-powerpc/2003/debian-powerpc-200306/msg00047.= html Thanks. Cheers, --=20 J=E9r=F4me Marant http://marant.org |
From: Michel <mi...@da...> - 2003-07-23 22:40:05
|
On Sat, 2003-07-19 at 10:51, Jérôme Marant wrote: > > Paul Zaremba <pe...@tr...> writes: > > > jm...@ne... wrote: > >> > >> I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) > >> with a 20030504 snapshot of DRI (xlibmesa-gl1) and I experienced > >> glitches. I tried a 20030425 snapshot which worked fine (but much > >> slower IMO) so I guess something broke in between. > >> > > By "glitches" do you mean texture flickering and the like? > > For example, when you jump the sardine outline flickers. > > Yes, like that. And fishes appear as rectangles, as well as > trees. BTW, does setting RADEON_AGPTEXTURING_FORCE_DISABLE work around it? If so, Ian is working on fixing it. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: <jm...@ne...> - 2003-07-26 12:34:12
|
Michel D=E4nzer <mi...@da...> writes: =20 >> Yes, like that. And fishes appear as rectangles, as well as >> trees. > > BTW, does setting RADEON_AGPTEXTURING_FORCE_DISABLE work around it? If > so, Ian is working on fixing it. I've tried export RADEON_AGPTEXTURING_FORCE_DISABLE=3D1 and it seems to works fine now. Thanks a lot. Cheers, --=20 J=E9r=F4me Marant http://marant.org |
From: Ian R. <id...@us...> - 2003-07-29 20:41:44
Attachments:
r100_agptex.patch
|
J=E9r=F4me Marant wrote: > Michel D=E4nzer <mi...@da...> writes: > =20 >=20 >>>Yes, like that. And fishes appear as rectangles, as well as >>>trees. >> >>BTW, does setting RADEON_AGPTEXTURING_FORCE_DISABLE work around it? If >>so, Ian is working on fixing it. >=20 > I've tried export RADEON_AGPTEXTURING_FORCE_DISABLE=3D1 and it seems > to works fine now. Here is a patch that should fix the root of the problem. There are a=20 couple things about the patch that I don't like, which I why I haven't=20 already commited it. 1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 indirect buffers. This was copied directly from the R200 driver, but I=20 don't like it. We may want to change the size of this buffer at some=20 point, and hard-coding the value into the client-side driver will make=20 that difficult. 2. I don't like the hackish handing of the pre-1.3 DRM case. Are there=20 other PCI IDs that need the 128MB offset? Do we even support the=20 pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't=20 intend to fix the support), I'd like to chop all the pre-1.3 stuff out.=20 That will make the Radeon driver "look" a lot more like the R200=20 driver. That's a good thing IMHO. Thoughs? |
From: Keith W. <ke...@tu...> - 2003-07-29 21:37:46
|
Ian Romanick wrote: > J=E9r=F4me Marant wrote: >=20 >> Michel D=E4nzer <mi...@da...> writes: >> =20 >> >>>> Yes, like that. And fishes appear as rectangles, as well as >>>> trees. >>> >>> >>> BTW, does setting RADEON_AGPTEXTURING_FORCE_DISABLE work around it? I= f >>> so, Ian is working on fixing it. >> >> >> I've tried export RADEON_AGPTEXTURING_FORCE_DISABLE=3D1 and it seems >> to works fine now. >=20 >=20 > Here is a patch that should fix the root of the problem. There are a=20 > couple things about the patch that I don't like, which I why I haven't=20 > already commited it. >=20 > 1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 > indirect buffers. This was copied directly from the R200 driver, but I= =20 > don't like it. We may want to change the size of this buffer at some=20 > point, and hard-coding the value into the client-side driver will make=20 > that difficult. Agreed. > 2. I don't like the hackish handing of the pre-1.3 DRM case. Are there= =20 > other PCI IDs that need the 128MB offset? Do we even support the=20 > pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't=20 > intend to fix the support), I'd like to chop all the pre-1.3 stuff out.= =20 > That will make the Radeon driver "look" a lot more like the R200=20 > driver. That's a good thing IMHO. I think we should drop the pre-1.3 support. It's broken & would take a f= air=20 effort to fix. Keith |
From: Andreas S. <A.S...@gm...> - 2003-07-29 21:38:36
|
Am 2003.07.29 22:41:30 +0200 schrieb(en) Ian Romanick: =2E.. >=20 > 2. I don't like the hackish handing of the pre-1.3 DRM case. Are there= =20 > other PCI IDs that need the 128MB offset? Do we even support the=20 > pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't=20 > intend to fix the support), I'd like to chop all the pre-1.3 stuff out.= =20 > That will make the Radeon driver "look" a lot more like the R200=20 > driver. That's a good thing IMHO. >=20 > Thoughs? > I thought that even DRI shipped with XFree86 4.3.0 needs at least a 1.3 radeon.o DRM kernelmodule. (someone should verify) Just export RADEON_COMPAT=3D1 and try glxgears. -> assert =2E.. > /* Constants */ > +/* Do not use this value. For the R100, which can have upto 64MB of on-= card > + * memory, this should be 0x04000000. However, I believe that for the R= V200 > + * (i.e., Radeon 7500), which can have upto 128MB of on-card memory, this > + * should be 0x08000000. The Radeon DRM version 1.8 and higher has a ca= ll > + * to get the actual base of the AGP texture heap in the card's address > + * space. Use that instead! > + */ shouldnt agp-texturing just get disabled when an older kernelmodule is dete= cted that doesnt support that necessary call ? =2E.. greetings, Andreas |
From: Michel <mi...@da...> - 2003-07-29 22:16:45
|
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: > > 1. I don't like the hard-coding of 2*1024*1024 as the size of the > indirect buffers. This was copied directly from the R200 driver, but I > don't like it. We may want to change the size of this buffer at some > point, and hard-coding the value into the client-side driver will make > that difficult. > > 2. I don't like the hackish handing of the pre-1.3 DRM case. Are there > other PCI IDs that need the 128MB offset? Do we even support the > pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't > intend to fix the support), I'd like to chop all the pre-1.3 stuff out. > That will make the Radeon driver "look" a lot more like the R200 > driver. That's a good thing IMHO. Why not always use ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + dri_priv->agpTexOffset as discussed on IRC? This should work with any chip, memory layout, ... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Ian R. <id...@us...> - 2003-08-04 18:48:49
Attachments:
r100_agptex-02.patch
|
Michel D=C3=A4nzer wrote: > On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:=20 >=20 >>1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 >>indirect buffers. This was copied directly from the R200 driver, but I= =20 >>don't like it. We may want to change the size of this buffer at some=20 >>point, and hard-coding the value into the client-side driver will make=20 >>that difficult. >> >>2. I don't like the hackish handing of the pre-1.3 DRM case. Are there= =20 >>other PCI IDs that need the 128MB offset? Do we even support the=20 >>pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't=20 >>intend to fix the support), I'd like to chop all the pre-1.3 stuff out.= =20 >> That will make the Radeon driver "look" a lot more like the R200=20 >>driver. That's a good thing IMHO. >=20 > Why not always use=20 >=20 > ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + > dri_priv->agpTexOffset >=20 > as discussed on IRC? This should work with any chip, memory layout, ... Here's my inner conflict about that. If there's a perfectly good way to=20 get this value with a simple INREG, why is there an ioctl to get it as we= ll? In any case, here's an updated version of the patch that uses that method. |
From: Michel <mi...@da...> - 2003-08-04 21:01:28
|
On Mon, 2003-08-04 at 20:48, Ian Romanick wrote: > Michel Dänzer wrote: > > > On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: > > > >>1. I don't like the hard-coding of 2*1024*1024 as the size of the > >>indirect buffers. This was copied directly from the R200 driver, but I > >>don't like it. We may want to change the size of this buffer at some > >>point, and hard-coding the value into the client-side driver will make > >>that difficult. > >> > >>2. I don't like the hackish handing of the pre-1.3 DRM case. Are there > >>other PCI IDs that need the 128MB offset? Do we even support the > >>pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't > >>intend to fix the support), I'd like to chop all the pre-1.3 stuff out. > >> That will make the Radeon driver "look" a lot more like the R200 > >>driver. That's a good thing IMHO. > > > > Why not always use > > > > ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + > > dri_priv->agpTexOffset > > > > as discussed on IRC? This should work with any chip, memory layout, ... > > Here's my inner conflict about that. If there's a perfectly good way to > get this value with a simple INREG, why is there an ioctl to get it as well? Because nobody thought of the simple solution? :) Or maybe we wanted to get rid of the MMIO mapping? I don't know. If in doubt, I'd consider the chip register authoritative though. :) > Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h > =================================================================== > RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v > retrieving revision 1.29 > diff -u -d -r1.29 radeon_reg.h > --- programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h 10 Jun 2003 18:52:57 -0000 1.29 > +++ programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h 4 Aug 2003 18:45:45 -0000 > @@ -1882,7 +1882,15 @@ > > > /* Constants */ > +/* Do not use this value. For the R100, which can have upto 64MB of on-card > + * memory, this should be 0x04000000. However, I believe that for the RV200 > + * (i.e., Radeon 7500), which can have upto 128MB of on-card memory, this > + * should be 0x08000000. Use "(INREG( RADEON_MC_AGP_LOCATION ) & 0x0ffffU) > + * << 16" instead. > + */ > +#if 0 > #define RADEON_AGP_TEX_OFFSET 0x02000000 > +#endif > > #define RADEON_LAST_FRAME_REG RADEON_GUI_SCRATCH_REG0 > #define RADEON_LAST_CLEAR_REG RADEON_GUI_SCRATCH_REG2 Can't we just get rid of this? The value it was supposed to represent was never a constant in the first place. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2003-08-05 15:21:41
|
Ian Romanick wrote: > Michel D=C3=A4nzer wrote: >=20 >> On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: >> >>> 1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 >>> indirect buffers. This was copied directly from the R200 driver, but= =20 >>> I don't like it. We may want to change the size of this buffer at=20 >>> some point, and hard-coding the value into the client-side driver=20 >>> will make that difficult. >>> >>> 2. I don't like the hackish handing of the pre-1.3 DRM case. Are=20 >>> there other PCI IDs that need the 128MB offset? Do we even support=20 >>> the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and=20 >>> don't intend to fix the support), I'd like to chop all the pre-1.3=20 >>> stuff out. That will make the Radeon driver "look" a lot more like=20 >>> the R200 driver. That's a good thing IMHO. >> >> >> Why not always use >> ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + >> dri_priv->agpTexOffset >> >> as discussed on IRC? This should work with any chip, memory layout, ... >=20 >=20 > Here's my inner conflict about that. If there's a perfectly good way t= o=20 > get this value with a simple INREG, why is there an ioctl to get it as=20 > well? Oversight on my part. There are so many spaces that these things can be=20 expressed in, I found one that I knew worked for sure (ie that value in t= he=20 kernel) and ran with it. Anyway, is an ioctl really heavier-weight than an INREG? Keith |
From: Ian R. <id...@us...> - 2003-08-05 16:52:38
|
Keith Whitwell wrote: > Ian Romanick wrote: >> Michel D=C3=A4nzer wrote: >>> On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: >>> >>>> 1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 >>>> indirect buffers. This was copied directly from the R200 driver,=20 >>>> but I don't like it. We may want to change the size of this buffer=20 >>>> at some point, and hard-coding the value into the client-side driver= =20 >>>> will make that difficult. >>>> >>>> 2. I don't like the hackish handing of the pre-1.3 DRM case. Are=20 >>>> there other PCI IDs that need the 128MB offset? Do we even support=20 >>>> the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and=20 >>>> don't intend to fix the support), I'd like to chop all the pre-1.3=20 >>>> stuff out. That will make the Radeon driver "look" a lot more like=20 >>>> the R200 driver. That's a good thing IMHO. >>> >>> Why not always use >>> ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + >>> dri_priv->agpTexOffset >>> >>> as discussed on IRC? This should work with any chip, memory layout, .= .. >> >> Here's my inner conflict about that. If there's a perfectly good way=20 >> to get this value with a simple INREG, why is there an ioctl to get it= =20 >> as well? >=20 > Oversight on my part. There are so many spaces that these things can b= e=20 > expressed in, I found one that I knew worked for sure (ie that value in= =20 > the kernel) and ran with it. >=20 > Anyway, is an ioctl really heavier-weight than an INREG? It probably depends on the platform, I guess. I mis-spoke a bit. The=20 ioctl and the INREG do result in different values. The ioctl gets the=20 base address of the indirect buffers and the INREG gives the base of AGP=20 memory. Either can be used to calculate the base of textures in AGP=20 memory. I think the INREG method is *better*, even for the R200=20 drivers, because it avoids the hard-coded '+ 2*1024*1024'. Michel, does that INREG work for PCIGART as well? |
From: Michel <mi...@da...> - 2003-08-05 17:15:45
|
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote: > Keith Whitwell wrote: > > Ian Romanick wrote: > >> Michel Dänzer wrote: > >>> On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: > >>> > >>>> 1. I don't like the hard-coding of 2*1024*1024 as the size of the > >>>> indirect buffers. This was copied directly from the R200 driver, > >>>> but I don't like it. We may want to change the size of this buffer > >>>> at some point, and hard-coding the value into the client-side driver > >>>> will make that difficult. > >>>> > >>>> 2. I don't like the hackish handing of the pre-1.3 DRM case. Are > >>>> there other PCI IDs that need the 128MB offset? Do we even support > >>>> the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and > >>>> don't intend to fix the support), I'd like to chop all the pre-1.3 > >>>> stuff out. That will make the Radeon driver "look" a lot more like > >>>> the R200 driver. That's a good thing IMHO. > >>> > >>> Why not always use > >>> ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + > >>> dri_priv->agpTexOffset > >>> > >>> as discussed on IRC? This should work with any chip, memory layout, ... > >> > >> Here's my inner conflict about that. If there's a perfectly good way > >> to get this value with a simple INREG, why is there an ioctl to get it > >> as well? > > > > Oversight on my part. There are so many spaces that these things can be > > expressed in, I found one that I knew worked for sure (ie that value in > > the kernel) and ran with it. > > > > Anyway, is an ioctl really heavier-weight than an INREG? > > It probably depends on the platform, I guess. I mis-spoke a bit. The > ioctl and the INREG do result in different values. The ioctl gets the > base address of the indirect buffers and the INREG gives the base of AGP > memory. Either can be used to calculate the base of textures in AGP > memory. I think the INREG method is *better*, even for the R200 > drivers, because it avoids the hard-coded '+ 2*1024*1024'. It's sure better than that, but maybe Keith meant RADEON_PARAM_AGP_BASE? > Michel, does that INREG work for PCIGART as well? No, good point, you need INREG( RADEON_AIC_LO_ADDR ) + dri_priv->agpTexOffset for that. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Ian R. <id...@us...> - 2003-08-07 20:37:34
Attachments:
r100_agptex-03.patch
|
Michel D=C3=A4nzer wrote: > On Tue, 2003-08-05 at 18:52, Ian Romanick wrote: >=20 >>Keith Whitwell wrote: >> >>>Ian Romanick wrote: >>> >>>>Michel D=C3=A4nzer wrote: >>>> >>>>>On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: >>>>> >>>>> >>>>>>1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 >>>>>>indirect buffers. This was copied directly from the R200 driver,=20 >>>>>>but I don't like it. We may want to change the size of this buffer= =20 >>>>>>at some point, and hard-coding the value into the client-side drive= r=20 >>>>>>will make that difficult. >>>>>> >>>>>>2. I don't like the hackish handing of the pre-1.3 DRM case. Are=20 >>>>>>there other PCI IDs that need the 128MB offset? Do we even support= =20 >>>>>>the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and=20 >>>>>>don't intend to fix the support), I'd like to chop all the pre-1.3=20 >>>>>>stuff out. That will make the Radeon driver "look" a lot more like= =20 >>>>>>the R200 driver. That's a good thing IMHO. >>>>> >>>>>Why not always use >>>>>( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + >>>>>dri_priv->agpTexOffset >>>>> >>>>>as discussed on IRC? This should work with any chip, memory layout, = ... >>>> >>>>Here's my inner conflict about that. If there's a perfectly good way= =20 >>>>to get this value with a simple INREG, why is there an ioctl to get i= t=20 >>>>as well? >>> >>>Oversight on my part. There are so many spaces that these things can = be=20 >>>expressed in, I found one that I knew worked for sure (ie that value i= n=20 >>>the kernel) and ran with it. >>> >>>Anyway, is an ioctl really heavier-weight than an INREG? >> >>It probably depends on the platform, I guess. I mis-spoke a bit. The=20 >>ioctl and the INREG do result in different values. The ioctl gets the=20 >>base address of the indirect buffers and the INREG gives the base of AG= P=20 >>memory. Either can be used to calculate the base of textures in AGP=20 >>memory. I think the INREG method is *better*, even for the R200=20 >>drivers, because it avoids the hard-coded '+ 2*1024*1024'. >=20 > It's sure better than that, but maybe Keith meant RADEON_PARAM_AGP_BASE= ? >=20 >>Michel, does that INREG work for PCIGART as well? >=20 > No, good point, you need >=20 > INREG( RADEON_AIC_LO_ADDR ) + dri_priv->agpTexOffset >=20 > for that. Okay, that would be easy enough to add later. Right now neither driver=20 supports PCIGART texturing. It probably should be added at some point. In any case, here is what I hope will be the final version of this=20 patch. I have modified the R200 driver to use the same technique to get=20 agp_texture_offset. The required the use of a couple radeon_*.h header=20 files. I hope that's okay. I have tested this on my Radeon 8500 and it=20 works correctly (i.e., gets the same value in agp_texture_offset as the=20 old method). I'd like to commit this either today or tomorrow. |
From: Michel <mi...@da...> - 2003-08-07 21:11:16
|
On Thu, 2003-08-07 at 21:57, Ian Romanick wrote: > Michel Dänzer wrote: > > > On Tue, 2003-08-05 at 18:52, Ian Romanick wrote: > > > >>Michel, does that INREG work for PCIGART as well? > > > > No, good point, you need > > > > INREG( RADEON_AIC_LO_ADDR ) + dri_priv->agpTexOffset > > > > for that. > > Okay, that would be easy enough to add later. Right now neither driver > supports PCIGART texturing. It probably should be added at some point. Indeed, I've been working a bit on removing the artificial PCI GART limitations, I hope to post something soon, I won't have much time over the weekend though. > In any case, here is what I hope will be the final version of this > patch. I have modified the R200 driver to use the same technique to get > agp_texture_offset. The required the use of a couple radeon_*.h header > files. I hope that's okay. It was a matter of time. :) This patch looks great to me. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Riot777 <ri...@po...> - 2003-08-05 18:43:53
|
On Tue, 05 Aug 2003 09:52:25 -0700 Ian Romanick <id...@us...> wrote: > Keith Whitwell wrote: > > Ian Romanick wrote: > >> Michel D=E4nzer wrote: > >>> On Tue, 2003-07-29 at 22:41, Ian Romanick wrote: > >>> > >>>> 1. I don't like the hard-coding of 2*1024*1024 as the size of the=20 > >>>> indirect buffers. This was copied directly from the R200 driver,=20 > >>>> but I don't like it. We may want to change the size of this buffer= =20 > >>>> at some point, and hard-coding the value into the client-side driver= =20 > >>>> will make that difficult. > >>>> > >>>> 2. I don't like the hackish handing of the pre-1.3 DRM case. Are=20 > >>>> there other PCI IDs that need the 128MB offset? Do we even support= =20 > >>>> the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and=20 > >>>> don't intend to fix the support), I'd like to chop all the pre-1.3=20 > >>>> stuff out. That will make the Radeon driver "look" a lot more like= =20 > >>>> the R200 driver. That's a good thing IMHO. > >>> > >>> Why not always use > >>> ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0xffff ) << 16 ) + > >>> dri_priv->agpTexOffset > >>> > >>> as discussed on IRC? This should work with any chip, memory layout, .= .. > >> > >> Here's my inner conflict about that. If there's a perfectly good way= =20 > >> to get this value with a simple INREG, why is there an ioctl to get it= =20 > >> as well? > >=20 > > Oversight on my part. There are so many spaces that these things can b= e=20 > > expressed in, I found one that I knew worked for sure (ie that value in= =20 > > the kernel) and ran with it. > >=20 > > Anyway, is an ioctl really heavier-weight than an INREG? >=20 > It probably depends on the platform, I guess. I mis-spoke a bit. The=20 > ioctl and the INREG do result in different values. The ioctl gets the=20 > base address of the indirect buffers and the INREG gives the base of AGP= =20 > memory. Either can be used to calculate the base of textures in AGP=20 > memory. I think the INREG method is *better*, even for the R200=20 > drivers, because it avoids the hard-coded '+ 2*1024*1024'. >=20 > Michel, does that INREG work for PCIGART as well? >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel >=20 Keep working on it guys maybe my Wolfenstein and Tribes2 textures probs wil= l be ever fix. I'm going to download latest snapshot. Regards Riot777=20 --=20 #-------------------------------------------------------------# | Let the riot be there... | | | <http://riot777-hideout.prv.pl> | Slackware Linux - | | | The Penguin never sleeps | | This mail was sent by Riot777 | <http://slackware.com> | | Linux Registered User #252508 | | | <http://counter.li.org> | | #-------------------------------------------------------------# |
From: Paul Z. <pza...@te...> - 2003-07-18 18:07:33
|
The dri-devel list may get this twice, I was using a different email address than I had registered to send last time and it is pending list administrator approval. I registered my send address with the dri-devel list and am re-sending this to the list (but not to jmarant - he already received the message). jm...@ne... wrote: >[ Please CC me on reply, I'm not subscribed ] > > Hi, > > I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) > with a 20030504 snapshot of DRI (xlibmesa-gl1) and I experienced > glitches. I tried a 20030425 snapshot which worked fine (but much > slower IMO) so I guess something broke in between. > > By "glitches" do you mean texture flickering and the like? For example, when you jump the sardine outline flickers. I've seen something on x86. I mention it because I don't see a Bug. Maybe they are related and a Bug needs to be opened. If you set the environment variable R200_NO_TCL to 1 it would go away because it's using the software TCL. Maybe the old snapshot was using software TCL? Other symptoms: bzflag - fire a shot and the walls flicker like it's World War 3 Neverwinter Nights - "terminator syndrome" (characters all look like the T-1000 shifting if Env. mapping is enabled) I have a Radeon 8500LE (R200) on a VIA chipset board with an Athlon XP 1800+ (1.5ghz). Using gentoo with ACCEPT_KEYWORDS="~x86". I've also noticed that it looks like the "full screen" GL window for screen savers is off by 1 pixel. There is pixel garbage around the bottom and right sides of the screen if I use the OpenGL screen savers. My apologies if these problems are already fixed in the CVS, I haven't had time to experiment with downloading/compiling DRI out of CVS yet. Paul |
From: Michel <mi...@da...> - 2003-07-19 13:00:38
|
On Fri, 2003-07-18 at 13:45, jm...@ne... wrote: > > I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) BTW, the 7500 is an R100 core and hence doesn't use the r200 but the radeon driver. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: <jm...@ne...> - 2003-07-19 13:01:10
|
Michel D=E4nzer <mi...@da...> writes: > On Fri, 2003-07-18 at 13:45, jm...@ne... wrote: >>=20 >> I tried Tuxracer on a powerpc machine + an ATI 7500 (r200) > > BTW, the 7500 is an R100 core and hence doesn't use the r200 but the > radeon driver. Indeed, it is rv200, not r200.=20 --=20 J=E9r=F4me Marant http://marant.org |
From: Ian R. <id...@us...> - 2003-08-08 20:41:17
|
Michel D=C3=A4nzer wrote: > On Thu, 2003-08-07 at 21:57, Ian Romanick wrote: >>Michel D=C3=A4nzer wrote: >>>On Tue, 2003-08-05 at 18:52, Ian Romanick wrote: >>> >>>>Michel, does that INREG work for PCIGART as well? >>> >>>No, good point, you need >>> >>>INREG( RADEON_AIC_LO_ADDR ) + dri_priv->agpTexOffset >>> >>>for that. >> >>Okay, that would be easy enough to add later. Right now neither driver= =20 >>supports PCIGART texturing. It probably should be added at some point. >=20 > Indeed, I've been working a bit on removing the artificial PCI GART > limitations, I hope to post something soon, I won't have much time over > the weekend though. Cool. I'll be looking forward to that. :) In reference to your question on IRC about that r128 driver, it would=20 probably work to make similar changes to that driver. However, I don't=20 think there's much point. Every existing card uses the same value, and=20 I can't invision ATI making a new 64MB or 128MB version of that chip. :) >>In any case, here is what I hope will be the final version of this=20 >>patch. I have modified the R200 driver to use the same technique to ge= t=20 >>agp_texture_offset. The required the use of a couple radeon_*.h header= =20 >>files. I hope that's okay. =20 >=20 > It was a matter of time. :) This patch looks great to me. I decided that it was easier to do that than add duplicate of the INREG=20 macro and RADEON_MC_AGP_LOCATION contant in the r200 specific header=20 files. IMHO, we'd be better of the just have the r200 specific=20 registers, etc. in r200_reg.h and have the common ones in radeon_reg.h.=20 That would remove some of the textual differences (i.e., that diff=20 shows) between the two drivers. Alas, it would take a lot of effort to=20 change at this point with very little to gain. As you may have noticed from dri-patches, the code is now committed. :) |
From: Michel <mi...@da...> - 2003-08-08 22:21:37
|
On Fri, 2003-08-08 at 22:40, Ian Romanick wrote: > Michel Dänzer wrote: > > On Thu, 2003-08-07 at 21:57, Ian Romanick wrote: > >>Michel Dänzer wrote: > >>>On Tue, 2003-08-05 at 18:52, Ian Romanick wrote: > >>> > >>>>Michel, does that INREG work for PCIGART as well? > >>> > >>>No, good point, you need > >>> > >>>INREG( RADEON_AIC_LO_ADDR ) + dri_priv->agpTexOffset > >>> > >>>for that. > >> > >>Okay, that would be easy enough to add later. Right now neither driver > >>supports PCIGART texturing. It probably should be added at some point. > > > > Indeed, I've been working a bit on removing the artificial PCI GART > > limitations, I hope to post something soon, I won't have much time over > > the weekend though. > > Cool. I'll be looking forward to that. :) > > In reference to your question on IRC about that r128 driver, it would > probably work to make similar changes to that driver. However, I don't > think there's much point. Every existing card uses the same value, and > I can't invision ATI making a new 64MB or 128MB version of that chip. :) True. :) The memory layout is also hardcoded in this value, but there's probably less incentive to ever change that in the r128 driver as well. > >>I have modified the R200 driver to use the same technique to get > >>agp_texture_offset. The required the use of a couple radeon_*.h header > >>files. I hope that's okay. > > > > It was a matter of time. :) This patch looks great to me. > > I decided that it was easier to do that than add duplicate of the INREG > macro and RADEON_MC_AGP_LOCATION contant in the r200 specific header > files. IMHO, we'd be better of the just have the r200 specific > registers, etc. in r200_reg.h and have the common ones in radeon_reg.h. Absolutely. > That would remove some of the textual differences (i.e., that diff > shows) between the two drivers. Alas, it would take a lot of effort to > change at this point with very little to gain. I'm not sure I agree. The gain may be little right now, but it might prevent further duplication and inconsistencies between the drivers, which might prove to be a big gain in the future. I'm aware though that these are many 'may's and 'might's. :\ -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |