From: Gareth H. <ga...@va...> - 2001-03-27 11:19:53
|
Alan Hourihane wrote: > > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/mga/ > Changes by: alanh@usw-pr-cvs1. 01/03/27 03:13:09 > > Log message: > (portability fix) > enclose calling an interrupt with i386 ifdef. Do we really need this ? I'll take a look at this later tonight. Part of my MGA work was to remove all the ioctls from the client-side code, and there's still a little work left (AGP blits to be exact). All calls to ioctl() should be replaced with corresponding DRM lib calls (drmMGA* for MGA-specific ones). -- Gareth |
From: Felix <fx...@gm...> - 2002-10-02 00:44:34
|
Keith, you got the condition for waiting for an interrupt wrong. r200_ioctl.c, line 330 ... /* if there was a previous frame, wait for its IRQ */ - if (iw->irq_seq != -1 && sarea->last_frame < r200GetLastFrame( rmesa ) ) { + if (iw->irq_seq != -1 && r200GetLastFrame( rmesa ) < sarea->last_frame ) { UNLOCK_HARDWARE( rmesa ); ret = drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(*iw) ); ... Compare with my original patch. Felix On Tue, 01 Oct 2002 03:58:03 -0700 Keith Whitwell <ke...@us...> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/r200/ > Changes by: keithw@usw-pr-cvs1. 02/10/01 03:58:03 > > Log message: > A version of Felix's irq-wait patch > > Modified files: > xc/xc/lib/GL/mesa/src/drv/r200/: > r200_context.c r200_context.h r200_ioctl.c > > Revision Changes Path > 1.8 +1 -0 xc/xc/lib/GL/mesa/src/drv/r200/r200_context.c > 1.5 +1 -0 xc/xc/lib/GL/mesa/src/drv/r200/r200_context.h > 1.6 +43 -49 xc/xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c > > > > ------------------------------------------------------- > This sf.net email is sponsored by: DEDICATED SERVERS only $89! > Linux or FreeBSD, FREE setup, FAST network. Get your own server > today at http://www.ServePath.com/indexfm.htm > _______________________________________________ > Dri-patches mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-patches > > __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2002-10-02 07:57:10
|
Felix K=FChling wrote: > Keith, >=20 > you got the condition for waiting for an interrupt wrong. >=20 > r200_ioctl.c, line 330 > ... > /* if there was a previous frame, wait for its IRQ */ > - if (iw->irq_seq !=3D -1 && sarea->last_frame < r200GetLastFrame( = rmesa ) ) { > + if (iw->irq_seq !=3D -1 && r200GetLastFrame( rmesa ) < sarea->las= t_frame ) { > UNLOCK_HARDWARE( rmesa );=20 > ret =3D drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(*= iw) ); > ... OK, fixed. Keith |
From: Martin S. <Mar...@un...> - 2003-03-04 17:58:14
|
Michel Daenzer <mda...@us...> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > Changes by: mdaenzer@sc8-pr-cvs1. 03/03/03 17:02:35 > Log message: > Set Mesa hooks to flush vertices on state changes (Keith Whitwell) Whoooops, it appears to me that this fixes the FlightGear lockups. I did several tries of my usually reliable 'test routine' (starting with a viev straight out of the B747 cockpit) and it did _not_ crash the server until now. I'll try further. If this proves to be real maybe someone should contribute this as a patch against XFree86-4.3-branch .... ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Martin S. <Mar...@un...> - 2003-03-04 19:23:31
|
Martin Spott <Mar...@un...> wrote: > Michel Daenzer <mda...@us...> wrote: >> CVSROOT: /cvsroot/dri >> Module name: xc >> Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ >> Changes by: mdaenzer@sc8-pr-cvs1. 03/03/03 17:02:35 >> Log message: >> Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > Whoooops, it appears to me that this fixes the FlightGear lockups. This definitely looks to be stable for me so far with a Radeon7500. I'll be out of office for the rest of the week so I could not stress test this under different conditions. I'd be happy if others could confirm the sanitizing effect of these patches. I forgot to mention that I currently run the DRM driver from XFree86-4.3.0, I'll test others next week if anyone is interested. Thanks, Martin. P.S.: There's still the "dark lightning" issue with FG on Radeon .... ;-)) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Dieter <Die...@ha...> - 2003-03-07 14:06:39
|
Am Dienstag, 4. M=E4rz 2003 20:17 schrieb Martin Spott: > Martin Spott <Mar...@un...> wrote: > > Michel Daenzer <mda...@us...> wrote: > >> CVSROOT: /cvsroot/dri > >> Module name: xc > >> Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > >> Changes by: mdaenzer@sc8-pr-cvs1. 03/03/03 17:02:35 > >> > >> Log message: > >> Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > > > > Whoooops, it appears to me that this fixes the FlightGear lockups. > > This definitely looks to be stable for me so far with a Radeon7500. I'll = be > out of office for the rest of the week so I could not stress test this > under different conditions. I'd be happy if others could confirm the > sanitizing effect of these patches. > I forgot to mention that I currently run the DRM driver from XFree86-4.3.= 0, > I'll test others next week if anyone is interested. > > Thanks, > Martin. > P.S.: There's still the "dark lightning" issue with FG on Radeon .... ;-= )) Are all your TCL colors right? VTK (e.g. TaskParallelism, TaskParallelismWithPorts) have wrong (no colors)= on=20 the (inner) object polygons. R200_NO_TCL fix it. Charl, can you reproduce? Have you ever tried with several OpenGL apps in parallel? 5 times gears (no system load at all ;-) and then only one ipers =3D> hard = lock=20 up on my SMP system ;-( Texture vs. no texture thing? Regards, Dieter |
From: Michel <mi...@da...> - 2003-03-09 01:11:59
|
On Die, 2003-03-04 at 18:57, Martin Spott wrote: > Michel Daenzer <mda...@us...> wrote: > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > > Changes by: mdaenzer@sc8-pr-cvs1. 03/03/03 17:02:35 > > > Log message: > > Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > > Whoooops, it appears to me that this fixes the FlightGear lockups. I did > several tries of my usually reliable 'test routine' (starting with a viev > straight out of the B747 cockpit) and it did _not_ crash the server until > now. I'll try further. > > If this proves to be real maybe someone should contribute this as a patch > against XFree86-4.3-branch .... ;-) I've committed this change to the mesa-4-0-4-branch as well now, so you can verify whether it fixes the problems there as well. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Leif D. <lde...@re...> - 2003-03-27 15:19:19
|
I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. On Thu, 27 Mar 2003, Keith Whitwell wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/i810/ > Changes by: keithw@sc8-pr-cvs1. 03/03/27 00:46:48 > > Log message: > i830 wasn't reporting alpha component at 32bpp > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/i810/: > i830_dri.c > > Revision Changes Path > 1.11 +2 -2 xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.c > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Dri-patches mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-patches > -- Leif Delgass http://www.retinalburn.net |
From: Keith W. <ke...@tu...> - 2003-03-27 19:31:04
|
Leif Delgass wrote: > I removed the alpha component from the visuals because the 32 bit span > read function in i830_span.c doesn't read alpha from the framebuffer (it > always returns 255). There's a comment there saying that it should work > but doesn't. I think that should be fixed before advertising an alpha > channel. Also, I changed the bufferSize from 32 to 24, so that should be > changed back to 32 if an alpha channel is advertised. OK, I'll look into this. It's odd, because conform was working fine at 32bpp -- when did you make these changes? Keith |
From: Leif D. <lde...@re...> - 2003-03-27 20:01:24
|
On Thu, 27 Mar 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > I removed the alpha component from the visuals because the 32 bit span > > read function in i830_span.c doesn't read alpha from the framebuffer (it > > always returns 255). There's a comment there saying that it should work > > but doesn't. I think that should be fixed before advertising an alpha > > channel. Also, I changed the bufferSize from 32 to 24, so that should be > > changed back to 32 if an alpha channel is advertised. > > OK, I'll look into this. It's odd, because conform was working fine at 32bpp > -- when did you make these changes? > > Keith It was back when I did a mini-audit of the visuals being exported in several drivers before 4.3.0 (beginning of Feb.). Here's my original message about i830: http://marc.theaimsgroup.com/?l=dri-devel&m=104457580107963&w=2 The thread started here where I posted my orginal list of visuals exported by some of the drivers: http://marc.theaimsgroup.com/?l=dri-devel&m=104448416328979&w=2 There were fixes committed for a few other drivers as well. -- Leif Delgass http://www.retinalburn.net |
From: Keith W. <ke...@tu...> - 2003-03-27 20:08:04
|
Leif Delgass wrote: > On Thu, 27 Mar 2003, Keith Whitwell wrote: > > >>Leif Delgass wrote: >> >>>I removed the alpha component from the visuals because the 32 bit span >>>read function in i830_span.c doesn't read alpha from the framebuffer (it >>>always returns 255). There's a comment there saying that it should work >>>but doesn't. I think that should be fixed before advertising an alpha >>>channel. Also, I changed the bufferSize from 32 to 24, so that should be >>>changed back to 32 if an alpha channel is advertised. >> >>OK, I'll look into this. It's odd, because conform was working fine at 32bpp >>-- when did you make these changes? >> >>Keith > > > It was back when I did a mini-audit of the visuals being exported in > several drivers before 4.3.0 (beginning of Feb.). Here's my original > message about i830: > > http://marc.theaimsgroup.com/?l=dri-devel&m=104457580107963&w=2 > > The thread started here where I posted my orginal list of visuals exported > by some of the drivers: > > http://marc.theaimsgroup.com/?l=dri-devel&m=104448416328979&w=2 > > There were fixes committed for a few other drivers as well. Hmm. The code in the i830_span.c is definitely bogus. That's Jeff's comment, I'm pretty sure. I'll fix it, and the other issues you raised. Keith |
From: Keith W. <ke...@tu...> - 2003-03-28 11:47:30
|
Leif Delgass wrote: > On Thu, 27 Mar 2003, Keith Whitwell wrote: > > >>Leif Delgass wrote: >> >>>I removed the alpha component from the visuals because the 32 bit span >>>read function in i830_span.c doesn't read alpha from the framebuffer (it >>>always returns 255). There's a comment there saying that it should work >>>but doesn't. I think that should be fixed before advertising an alpha >>>channel. Also, I changed the bufferSize from 32 to 24, so that should be >>>changed back to 32 if an alpha channel is advertised. >> Hmm, changing this back doesn't seem to affect the output from glxinfo: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x22 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 'bf sz' is still 24, despite me setting bufferSize to 32 in i830_dri.c: pConfigs[i].bufferSize = 32; any clues, anyone? Keith |
From: Leif D. <lde...@re...> - 2003-03-28 14:59:38
|
On Fri, 28 Mar 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > On Thu, 27 Mar 2003, Keith Whitwell wrote: > > > > > >>Leif Delgass wrote: > >> > >>>I removed the alpha component from the visuals because the 32 bit span > >>>read function in i830_span.c doesn't read alpha from the framebuffer (it > >>>always returns 255). There's a comment there saying that it should work > >>>but doesn't. I think that should be fixed before advertising an alpha > >>>channel. Also, I changed the bufferSize from 32 to 24, so that should be > >>>changed back to 32 if an alpha channel is advertised. > >> > > Hmm, changing this back doesn't seem to affect the output from glxinfo: > > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > ---------------------------------------------------------------------- > 0x22 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > > > 'bf sz' is still 24, despite me setting bufferSize to 32 in i830_dri.c: > > pConfigs[i].bufferSize = 32; > > > any clues, anyone? > > Keith I ran into that as well, see: http://marc.theaimsgroup.com/?l=dri-devel&m=104457475806902&w=2 I think the code related to bufferSize in xc/programs/Xserver/GL/mesa/src/X/xf86glx.c is suspect regarding bufferSize. I think the X visual depth is being used instead of the sum of the channel sizes. There is a comment that a bufferSize of 32 "[...]may foul-up the visual matching code[...]". I haven't looked at it closely enough to see what would be needed to fix it. -- Leif Delgass http://www.retinalburn.net |
From: Ian R. <id...@us...> - 2003-03-28 16:07:41
|
Leif Delgass wrote: > I ran into that as well, see: > > http://marc.theaimsgroup.com/?l=dri-devel&m=104457475806902&w=2 > > I think the code related to bufferSize in > xc/programs/Xserver/GL/mesa/src/X/xf86glx.c is suspect regarding > bufferSize. I think the X visual depth is being used instead of the sum > of the channel sizes. There is a comment that a bufferSize of 32 > "[...]may foul-up the visual matching code[...]". I haven't looked at it > closely enough to see what would be needed to fix it. I just re-wrote the client-side visual matching code. I don't think having a buffer size of 32 would foul-up either the old or the new code. It doesn't match for an exact size. The buffer size in the visual has to be at least as large as the requested size, and a larger size if prefered over a smaller size. If the user requests 16, and 24 and 32 are available, assuming all other things are equal, they'll get 32. |
From: Leif D. <lde...@re...> - 2003-04-22 19:55:44
|
Disregard my comment about mga and __MUST_HAVE_AGP. It does define it, I was grepping in the wrong directory. At any rate, building the drm without CONFIG_AGP should work again now for r128, radeon, and sis (if you uncomment sis.o in MODULE_LIST). On Tue, 22 Apr 2003, Leif Delgass wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ > Changes by: ldelgass@sc8-pr-cvs1. 03/04/22 12:42:39 > > Log message: > Only mga, i810, i830 require AGP (should mga define __MUST_HAVE_AGP?) > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > Makefile.linux > > Revision Changes Path > 1.51 +9 -9 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Makefile.linux > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Dri-patches mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-patches > -- Leif Delgass http://www.retinalburn.net |
From: Leif D. <lde...@re...> - 2003-04-22 20:54:18
|
Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pcigart support will be included for all arches? The radeon DDX will now try to use pcigart with ForcePCIMode on any arch., but this will fail if the drm doesn't have support compiled in (by default this is only done for alpha and ppc now). The only arch-specific behavior in the DDX now is that pcigart is only used as a fallback (without ForcePCIMode) on alpha and ppc. I tried ForcePCIMode and it works for me on x86. Also, the dependency on AGP for the radeon module in Config.in and Kconfig should probably be removed. On Tue, 22 Apr 2003, Leif Delgass wrote: > Disregard my comment about mga and __MUST_HAVE_AGP. It does define it, I > was grepping in the wrong directory. At any rate, building the drm without > CONFIG_AGP should work again now for r128, radeon, and sis (if you > uncomment sis.o in MODULE_LIST). > > On Tue, 22 Apr 2003, Leif Delgass wrote: > > > CVSROOT: /cvsroot/dri > > Module name: xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ > > Changes by: ldelgass@sc8-pr-cvs1. 03/04/22 12:42:39 > > > > Log message: > > Only mga, i810, i830 require AGP (should mga define __MUST_HAVE_AGP?) > > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > > Makefile.linux > > > > Revision Changes Path > > 1.51 +9 -9 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Makefile.linux > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Dri-patches mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-patches > > > > -- Leif Delgass http://www.retinalburn.net |
From: Michel <mi...@da...> - 2003-04-22 21:15:12
|
On Die, 2003-04-22 at 22:53, Leif Delgass wrote: > Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pcigart > support will be included for all arches? Yes, it was removed in XFree86 CVS before 4.3.0 so it's a merge error if it's still there. > Also, the dependency on AGP for the radeon module in Config.in and Kconfig > should probably be removed. Absolutely. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Leif D. <lde...@re...> - 2003-04-22 21:34:13
|
On 22 Apr 2003, Michel D=E4nzer wrote: > On Die, 2003-04-22 at 22:53, Leif Delgass wrote: > > Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pcigart= > > support will be included for all arches? = > = > Yes, it was removed in XFree86 CVS before 4.3.0 so it's a merge error i= f > it's still there. > = > > Also, the dependency on AGP for the radeon module in Config.in and Kc= onfig > > should probably be removed. > = > Absolutely. Ok, I've fixed both of these in the DRI trunk. It appears that the PCIGART_ENABLED define is still in the drm in XFree86 CVS as well, so it wasn't a merge error. The define was removed from the DDX in both XFree8= 6 and DRI CVS however. -- = Leif Delgass = http://www.retinalburn.net |
From: Leif D. <lde...@re...> - 2003-04-22 21:49:23
|
On Tue, 22 Apr 2003, Leif Delgass wrote: > On 22 Apr 2003, Michel D=E4nzer wrote: > = > > On Die, 2003-04-22 at 22:53, Leif Delgass wrote: > > > Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pciga= rt > > > support will be included for all arches? = > > = > > Yes, it was removed in XFree86 CVS before 4.3.0 so it's a merge error= if > > it's still there. > > = > > > Also, the dependency on AGP for the radeon module in Config.in and = Kconfig > > > should probably be removed. > > = > > Absolutely. > = > Ok, I've fixed both of these in the DRI trunk. It appears that the > PCIGART_ENABLED define is still in the drm in XFree86 CVS as well, so i= t > wasn't a merge error. The define was removed from the DDX in both XFre= e86 > and DRI CVS however. Actually, it looks like it _was_ a merge error. PCIGART_ENABLED was removed from the XFree86 CVS radeon drm, but was added back in the sync David did a few days ago. I noticed another problem with that merge. = Charl Botha's DRI resume patch was committed to XFree86 CVS, which adds a= n ioctl to the radeon DRM. The DRM portion of that patch appears to have been reversed in the sync. I wonder if we should apply that patch to the= DRI tree to get synced up with the ioctls? In any case, the clobbered code will need to be restored in XFree86 CVS. -- = Leif Delgass = http://www.retinalburn.net |
From: Michel <mi...@da...> - 2003-04-22 22:09:05
|
On Die, 2003-04-22 at 23:48, Leif Delgass wrote: > On Tue, 22 Apr 2003, Leif Delgass wrote: > > > On 22 Apr 2003, Michel Dänzer wrote: > > > > > On Die, 2003-04-22 at 22:53, Leif Delgass wrote: > > > > Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pcigart > > > > support will be included for all arches? > > > > > > Yes, it was removed in XFree86 CVS before 4.3.0 so it's a merge error if > > > it's still there. > > > > > > > Also, the dependency on AGP for the radeon module in Config.in and Kconfig > > > > should probably be removed. > > > > > > Absolutely. > > > > Ok, I've fixed both of these in the DRI trunk. Thank you. > > It appears that the PCIGART_ENABLED define is still in the drm in XFree86 > > CVS as well, so it wasn't a merge error. The define was removed from > > the DDX in both XFree86 and DRI CVS however. > > Actually, it looks like it _was_ a merge error. PCIGART_ENABLED was > removed from the XFree86 CVS radeon drm, but was added back in the sync > David did a few days ago. I suspected so. BTW, I can recommend meld for anyone doing a merge, it's pretty nice, a three way radeon_driver.c merge pretty much killed it performance wise though. :) > I noticed another problem with that merge. Charl Botha's DRI resume > patch was committed to XFree86 CVS, which adds an ioctl to the radeon > DRM. The DRM portion of that patch appears to have been reversed in > the sync. I wonder if we should apply that patch to the DRI tree to > get synced up with the ioctls? Yes, and bump the minor version, and preferrably refactor the code a little to reduce duplication, ... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: David D. <dawes@XFree86.Org> - 2003-04-23 01:40:13
|
On Tue, Apr 22, 2003 at 04:48:15PM -0500, Leif Delgass wrote: >On Tue, 22 Apr 2003, Leif Delgass wrote: > >> On 22 Apr 2003, Michel D=E4nzer wrote: >>=20 >> > On Die, 2003-04-22 at 22:53, Leif Delgass wrote: >> > > Shouldn't PCIGART_ENABLED be removed from radeon_cp.c now, so pcig= art >> > > support will be included for all arches? =20 >> >=20 >> > Yes, it was removed in XFree86 CVS before 4.3.0 so it's a merge erro= r if >> > it's still there. >> >=20 >> > > Also, the dependency on AGP for the radeon module in Config.in and= Kconfig >> > > should probably be removed. >> >=20 >> > Absolutely. >>=20 >> Ok, I've fixed both of these in the DRI trunk. It appears that the >> PCIGART_ENABLED define is still in the drm in XFree86 CVS as well, so = it >> wasn't a merge error. The define was removed from the DDX in both XFr= ee86 >> and DRI CVS however. > >Actually, it looks like it _was_ a merge error. PCIGART_ENABLED was >removed from the XFree86 CVS radeon drm, but was added back in the sync >David did a few days ago. I noticed another problem with that merge. =20 I mistakenly assumed that the DRI trunk had all pre-4.3 changes, so didn'= t check back before then. >Charl Botha's DRI resume patch was committed to XFree86 CVS, which adds = an >ioctl to the radeon DRM. The DRM portion of that patch appears to have >been reversed in the sync. I wonder if we should apply that patch to th= e >DRI tree to get synced up with the ioctls? In any case, the clobbered >code will need to be restored in XFree86 CVS. Oops. I mistakenly assumed that all of this was in the DRI trunk already. I'll resync again, and put back Charl's resume patch. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes |
From: David D. <dawes@XFree86.Org> - 2003-04-23 01:45:29
|
On Wed, Apr 23, 2003 at 12:08:00AM +0200, Michel D=E4nzer wrote: >> I noticed another problem with that merge. Charl Botha's DRI resume=20 >> patch was committed to XFree86 CVS, which adds an ioctl to the radeon=20 >> DRM. The DRM portion of that patch appears to have been reversed in=20 >> the sync. I wonder if we should apply that patch to the DRI tree to=20 >> get synced up with the ioctls? > >Yes, and bump the minor version, and preferrably refactor the code a >little to reduce duplication, ... The radeon DRM minor version has already been bumped since 4.3. It doesn't need to be bumped again yet, does it? David --=20 David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes |
From: Michel <mi...@da...> - 2003-04-23 23:15:44
|
On Mit, 2003-04-23 at 03:45, David Dawes wrote: > On Wed, Apr 23, 2003 at 12:08:00AM +0200, Michel Dänzer wrote: > > >> I noticed another problem with that merge. Charl Botha's DRI resume > >> patch was committed to XFree86 CVS, which adds an ioctl to the radeon > >> DRM. The DRM portion of that patch appears to have been reversed in > >> the sync. I wonder if we should apply that patch to the DRI tree to > >> get synced up with the ioctls? > > > >Yes, and bump the minor version, and preferrably refactor the code a > >little to reduce duplication, ... > > The radeon DRM minor version has already been bumped since 4.3. It > doesn't need to be bumped again yet, does it? Well, as Linus merges the DRM fairly regularly between 2.5 kernels and DRI CVS, it's probably better to bump it more often rather than more rarely, or it can't be used to check for features. -- 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-04-22 21:58:55
|
Leif Delgass wrote: > Disregard my comment about mga and __MUST_HAVE_AGP. It does define it, I > was grepping in the wrong directory. At any rate, building the drm without > CONFIG_AGP should work again now for r128, radeon, and sis (if you > uncomment sis.o in MODULE_LIST). It shouldn't. There are still PCI G200s and PCI G450s out there. I see no reason why those cards shouldn't work on systems that don't have AGP available. :) |
From: Leif D. <lde...@re...> - 2003-04-22 22:36:49
|
On Tue, 22 Apr 2003, Ian Romanick wrote: > Leif Delgass wrote: > > Disregard my comment about mga and __MUST_HAVE_AGP. It does define it, I > > was grepping in the wrong directory. At any rate, building the drm without > > CONFIG_AGP should work again now for r128, radeon, and sis (if you > > uncomment sis.o in MODULE_LIST). > > It shouldn't. There are still PCI G200s and PCI G450s out there. I see > no reason why those cards shouldn't work on systems that don't have AGP > available. :) Does that mean you're volunteering to add PCI support? ;) I think the PCI changes necessary for mach64 could come in handy there. There's a microcode and "primary" DMA region that would probably need to be allocated with pci_alloc_consistent. Speaking of which, I've been looking a bit at what needs to be done to add mapping support to the PCI interface Jose proposed. One of the problems as I understand it is that virt_to_page() is not a valid operation on an address returned by pci_alloc_consistent(). I've seen a proposal for a pci_consistent_to_page() function for this purpose, but I don't think that's happened yet. -- Leif Delgass http://www.retinalburn.net |