Menu
▾
▴
dri-devel
|
From: Tim S. <ti...@el...> - 2002-05-23 23:59:31
|
I have a nice, 100% reliable way to lock up my Radeon 7500 using the most recent CVS. I can do this with Tux Racer, if I play for a couple of courses, but it's much easier to do using the Neverwinter Nights Toolset beta running under WINE, because that's really quite intensive and produces the lockup in about 5 seconds (much longer if debugging is enabled, which seems interesting). This was stable with the drivers in XFree 4.2, except that they would fail to texture things (e.g. the penguin in Tux Racer was a white blob). I've played around with *all* the radeon driver options in XF86Config, to no significant effect (well I managed to lock X on startup with a too-high CPusecTimeout :-). It won't let me assign more than 2MB to BufferSize and I presume there's a good reason for that, so 32 buffers seems the maximum unless the size of each buffer can be reduced. How much of that 64K gets used? Is it worth trying that? lspci tells me: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 04) 00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 01) 00:0b.0 SCSI storage controller: Adaptec AHA-7850 (rev 01) 00:0d.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 / HPT370 (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon 7500 QW I've got several yards of logs, but I'm not sure how much to post. I hope this sample is sufficient. Looking at the whole it seems that 'radeon_freelist_get' is having to do more and more work to find a free buffer. It starts out finding one on the first pass, but has to skip more and more as time goes on. Then it gets into its degenerate case and has to start looping hoping the card will have finished with one, which works for a while until it finally hits the dreaded kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! and everything goes pear-shaped. May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=20 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=21 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=22 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=23 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=24 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=25 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=26 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=27 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=28 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=29 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=30 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=31 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] ret buf=7 last=7 age=201025 done=201183 May 24 00:11:55 moomintroll kernel: [drm:radeon_ioctl] pid=3230, cmd=0xc004644d, nr=0x4d, dev 0xe200, auth=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_indirect] indirect: idx=7 s=0 e=240 d=0 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=7 s=0x0 e=0xf0 May 24 00:11:55 moomintroll kernel: [drm:radeon_ioctl] pid=3230, cmd=0xc004644d, nr=0x4d, dev 0xe200, auth=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_indirect] indirect: idx=7 s=240 e=488 d=0 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=7 s=0xf0 e=0x1e8 May 24 00:11:55 moomintroll kernel: [drm:radeon_ioctl] pid=3230, cmd=0xc004644d, nr=0x4d, dev 0xe200, auth=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_indirect] indirect: idx=7 s=488 e=504 d=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=7 s=0x1e8 e=0x1f8 May 24 00:11:55 moomintroll kernel: [drm:radeon_ioctl] pid=3230, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_idle] radeon_cp_idle May 24 00:11:55 moomintroll kernel: [drm:radeon_do_cp_idle] radeon_do_cp_idle May 24 00:11:55 moomintroll kernel: [drm:radeon_ioctl] pid=3230, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=0 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=1 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=2 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=3 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=4 pid=3230 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=5 pid=3230 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=6 pid=3230 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=7 pid=3230 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=8 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=9 pid=3235 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=10 pid=3230 May 24 00:11:55 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=11 pid=3235 *** Somewhere between here and the next (corrupted) line lies the "ERROR returning NULL!" line. I know this because it shows up with this timestamp in the less detailed syslog I send to a remote machine. I tried sending all this there but it dropped too much on the floor to be useful. May 24 00:11:55 moomintroll kernel: indirect: buf=13 s=0x7280 e=0x733c May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indices] indices: start=7700/7714 end=7774 count=48 nv 13773 offset 41d9340 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x7700 e=0x7774 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indices] indices: start=7b40/7b54 end=7bcc count=60 nv 13790 offset 41d9780 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x7b40 e=0x7bcc May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indices] indices: start=7f80/7f94 end=8000 count=54 nv 13808 offset 41d9c00 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x7f80 e=0x8000 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indices] indices: start=8420/8434 end=84d6 count=81 nv 13824 offset 41da000 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x8420 e=0x84d6 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_vertex] radeon_cp_dispatch_vertex: nbox=1 34008..34776 prim 4 nvert 24 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indices] indices: start=8c20/8c34 end=8cd6 count=81 nv 13856 offset 41da800 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_clip_rect] box: x1=544 y1=357 x2=1124 y2=906 May 24 00:11:55 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x8c20 e=0x8cd6 May 24 00:11:55 moomintroll kernel: [drm:radeon_emit_state] radeon_emit_state: dirty=0x00000201 ...and after more of the same I reboot -- Tim Smith (ti...@el...) Interfere? Of course we should interfere! Always do what you're best at, that's what I say. -- Doctor Who |
|
From: Keith W. <ke...@tu...> - 2002-05-24 07:50:15
|
Tim Smith wrote: > I have a nice, 100% reliable way to lock up my Radeon 7500 using the most > recent CVS. I can do this with Tux Racer, if I play for a couple of > courses, but it's much easier to do using the Neverwinter Nights Toolset > beta running under WINE, because that's really quite intensive and produces > the lockup in about 5 seconds (much longer if debugging is enabled, which > seems interesting). This was stable with the drivers in XFree 4.2, except > that they would fail to texture things (e.g. the penguin in Tux Racer was a > white blob). > > I've played around with *all* the radeon driver options in XF86Config, to no > significant effect (well I managed to lock X on startup with a too-high > CPusecTimeout :-). It won't let me assign more than 2MB to BufferSize and I > presume there's a good reason for that, so 32 buffers seems the maximum > unless the size of each buffer can be reduced. How much of that 64K gets > used? Is it worth trying that? It depends a little on which driver you're using. The two in CVS make full use of each buffer & only release it when it's full. XFree 4.2 driver is pretty primitive in some repects & fires after each (run of similar) primitive so can be quite wasteful. How does the CVS code hold up? You can download binaries from the sourceforge download page... URL? Keith |
|
From: Tim S. <ti...@el...> - 2002-05-24 10:15:43
|
On Friday 24 May 2002 8:49 am, Keith Whitwell scribed numinously:" > Tim Smith wrote: > > I have a nice, 100% reliable way to lock up my Radeon 7500 using the > > most recent CVS. I can do this with Tux Racer, if I play for a couple > > of courses, but it's much easier to do using the Neverwinter Nights > > Toolset beta running under WINE, because that's really quite intensive > > and produces the lockup in about 5 seconds (much longer if debugging is > > enabled, which seems interesting). This was stable with the drivers in > > XFree 4.2, except that they would fail to texture things (e.g. the > > penguin in Tux Racer was a white blob). > > > > I've played around with *all* the radeon driver options in XF86Config, > > to no significant effect (well I managed to lock X on startup with a > > too-high CPusecTimeout :-). It won't let me assign more than 2MB to > > BufferSize and I presume there's a good reason for that, so 32 buffers > > seems the maximum unless the size of each buffer can be reduced. How > > much of that 64K gets used? Is it worth trying that? > > It depends a little on which driver you're using. The two in CVS make > full use of each buffer & only release it when it's full. XFree 4.2 > driver is pretty primitive in some repects & fires after each (run of > similar) primitive so can be quite wasteful. > > How does the CVS code hold up? You can download binaries from the > sourceforge download page... URL? The XFree 4.2 driver is stable, but drops textures on the floor somwhere. The CVS code produces correct textures, but locks up under heavy use with the symptoms described. I've been using the binaries from dri.sourceforge.net to test this with. I also tried the experimental tcl branch binaries out of curiosity, but my X server segfaulted on startup so I stopped being so silly :-) I am using the X server checked out from cvs.dri.sourceforge.net I've been poking at it a bit more recently, just reading the code to see what it does because I'm not at the machine in question right now, and I observe the following in xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_accel.c, starting at line 1518 while ( 1 ) { do { ret = drmDMA( info->drmFD, &dma ); if ( ret && ret != -EBUSY ) { xf86DrvMsg( pScrn->scrnIndex, X_ERROR, "%s: CP GetBuffer %d\n", __FUNCTION__, ret ); } } while ( ( ret == -EBUSY ) && ( i++ < RADEON_TIMEOUT ) ); if ( ret == 0 ) { buf = &info->buffers->list[indx]; buf->used = 0; if ( RADEON_VERBOSE ) { xf86DrvMsg( pScrn->scrnIndex, X_INFO, " GetBuffer returning %d\n", buf->idx ); } return buf; } xf86DrvMsg( pScrn->scrnIndex, X_ERROR, "GetBuffer timed out, resetting engine...\n"); RADEONEngineReset( pScrn ); RADEONEngineRestore( pScrn ); /* Always restart the engine when doing CP 2D acceleration */ RADEONCP_RESET( pScrn, info ); RADEONCP_START( pScrn, info ); } What's going to happen to the card if drmDMA() returns EAGAIN rather than EBUSY, which is what it does in the case where radeon_freelist_get returns NULL? Should the drm kernel module return EBUSY in that circumstance? None of the userspace parts seem to check for EAGAIN, but all the drm modules seem to return it when freelist_get falls off the bottom. -- Tim Smith (ti...@el...) 75% of wookies over the age of three hundred wear hairpieces. |
|
From: Keith W. <ke...@tu...> - 2002-05-24 10:31:29
|
> > What's going to happen to the card if drmDMA() returns EAGAIN rather than > EBUSY, which is what it does in the case where radeon_freelist_get returns > NULL? Should the drm kernel module return EBUSY in that circumstance? None > of the userspace parts seem to check for EAGAIN, but all the drm modules > seem to return it when freelist_get falls off the bottom. drmDMA can legitimately fail in this way - if the card is busy and/or there are other active clients holding buffers. In that case, the client is expected to retry. The problem is that if the card has locked, you end up in the same place, and get people trying to fix this code, which is just the effect, not the cause of the problem. Keith |
|
From: Tim S. <ti...@el...> - 2002-05-24 18:34:45
|
On Friday 24 May 2002 11:31 am, Keith Whitwell scribed numinously:" +> > What's going to happen to the card if drmDMA() returns EAGAIN rather > > than EBUSY, which is what it does in the case where radeon_freelist_get > > returns NULL? Should the drm kernel module return EBUSY in that > > circumstance? None of the userspace parts seem to check for EAGAIN, but > > all the drm modules seem to return it when freelist_get falls off the > > bottom. > > drmDMA can legitimately fail in this way - if the card is busy and/or > there are other active clients holding buffers. > > In that case, the client is expected to retry. The problem is that if > the card has locked, you end up in the same place, and get people trying > to fix this code, which is just the effect, not the cause of the problem. OK, I was expecting EAGAIN to mean "please retry" and I guess I got a little confused that it retried 16 times for EAGAIN and 2 million for EBUSY. I've introduced a tiny usleep into the loop in radeon_accel.c to give syslog a chance and my loghost now produces a couple of thousand lines of the form moomintroll kernel: [drm:radeon_freelist_get] skipping buf=23 age=48355 done=48319 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=24 age=48356 done=48319 Covering about 30 seconds prior to me hitting reset, so the card certainly seems to be getting rather stuck, because 'done=N' doesn't increment over that 30 seconds. The lines immediately prior to this storm read: May 24 18:16:36 moomintroll kernel: [drm:radeon_freelist_get] ret buf=14 last=14 age=47687 done=47733 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_texture] tex: ofs=0xe240 p=32 f=7 x=0 y=310 w=512 h=202 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_texture] tex=2048x512 blit=2048 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0x0 e=0xf820 This isn't consistent though. Later I get a similar lockup and the logs are entirely different. Logs from a couple of tries are at http://www.electronghost.co.uk/radlock1.txt.gz Any ideas about where I should look? -- Tim Smith (ti...@el...) Interfere? Of course we should interfere! Always do what you're best at, that's what I say. -- Doctor Who |
|
From: Linus T. <tor...@tr...> - 2002-05-24 19:09:22
|
On Fri, 24 May 2002, Tim Smith wrote: > > Covering about 30 seconds prior to me hitting reset, so the card certainly > seems to be getting rather stuck, because 'done=N' doesn't increment over > that 30 seconds. Hmm.. I don't know if it is related, but you can get both a Radeon-7500 and a Radeon-8500 to lock up the X server completely even without any DRI, by just running the gatos server before you run the DRI server (without rebooting in between). That lockup happens immediately on server startup for me, so clearly some case isn't initialized or handled correctly. It might be easier to debug than the DRI lockup, and it _might_ just be the same thing. It might even happen with a regular XF-4.2 server (ie switching from using XF4.2 to DRI CVS tree without rebooting in between), I'll test. Linus |
|
From: Linus T. <tor...@tr...> - 2002-05-24 19:22:12
|
On Fri, 24 May 2002, Linus Torvalds wrote: > > It might even happen with a regular XF-4.2 server (ie switching from using > XF4.2 to DRI CVS tree without rebooting in between), I'll test. Nope, doesn't happen with regular XF-4.2. But I re-verified that if I run the gatos drivers first, and then exit X and install the DRI tree, the DRI tree will simply not work. Linus |
|
From: F. <j_r...@ya...> - 2002-05-24 19:51:33
|
On 2002.05.24 20:22 Linus Torvalds wrote: > > > On Fri, 24 May 2002, Linus Torvalds wrote: > > > > It might even happen with a regular XF-4.2 server (ie switching from > using > > XF4.2 to DRI CVS tree without rebooting in between), I'll test. > > Nope, doesn't happen with regular XF-4.2. But I re-verified that if I run > the gatos drivers first, and then exit X and install the DRI tree, the > DRI tree will simply not work. When doing this you're using the GATOS DRM with the Radeon Mesa & X drivers of DRI CVS. Since the regular X works, it seems that GATOS broke binary compatibility. Does this happens too when switching GATOS with XF-4.2? José Fonseca |
|
From: Linus T. <tor...@tr...> - 2002-05-24 20:09:23
|
On Fri, 24 May 2002, Jos=E9 Fonseca wrote: > > When doing this you're using the GATOS DRM with the Radeon Mesa & X > drivers of DRI CVS. Since the regular X works, it seems that GATOS brok= e > binary compatibility. Does this happens too when switching GATOS with > XF-4.2? Note that once I switch away from Gatos, nothing of Gatos is left behind, so it's more than a binary compatibility issue: Gatos puts the card in some state that the DRI tree simply cannot handle. And yes, you don't eve= n need the DRI branch, you can see the lockup even with gatos -> plain XFre= e CVS (I told Keith Packard about it, I haven't heard back). [ Aside: I haven't tried to used Gatos for any 3D stuff - this happens even with GLX/DRI not even loaded. ] The point being that even the tuxracer lockup may not have anything to do with 3D itself: it may be that the lockup is due to the same (generic XF) bug, and maybe the 3D pipeline triggers the same card state that Gatos somehow triggers: the card gets in some "busy" state that needs explicit help in clearing or something (and just waiting for the busy state to go away thus ends up being non-productive). Anyway, it was just a suggestion for an alternate thing to look at that might be more easily debuggable and _migth_ have common causes. I piped up just because I wanted to start merging the DRI kernel stuff into the 2.5.x kernel tree, so I started following the mailing list to se= e what the gotcha's are... My actual 3D testing itself is limited to just verifying that "glxgears" works at 1000 fps, so that I can be reasonably happy that the merge works to _some_ degree ;) Linus |
|
From: David S. M. <da...@re...> - 2002-05-24 20:15:13
|
From: Linus Torvalds <tor...@tr...> Date: Fri, 24 May 2002 13:09:18 -0700 (PDT) _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm Hmmm, where are these advertisement blobs coming from? Sourceforge??? Linus, you aren't selling advertisement space in your outgoing emails now are you? :-) |
|
From: Keith P. <ke...@ke...> - 2002-05-24 20:36:10
|
Around 13 o'clock on May 24, Linus Torvalds wrote: > And yes, you don't even need the DRI branch, you can see the lockup even > with gatos -> plain XFree CVS (I told Keith Packard about it, I haven't > heard back). About all I could do was reproduce the problem; I don't have radeon docs yet to try and figure things out. I've been off getting GTK+ 2.2, Mozilla and Qt3 font stuff straightened out. The existence of three separate development teams working on the radeon drivers is a bit of a problem, but I'm really unsure how to fix things. Probably the worst off right now is the XFree86 tree which has neither working video nor 3D on many radeon chips, and which routinely hangs when switching VTs. I currently run the tcl-0-0 branch on my desktop 7500 and XFree86 on my laptop M6 -- and that with DRI disabled so I can switch VTs. The tcl-0-0 branch doesn't display video correctly, but does 3D while the XFree86 tree doesn't do 3D, but does video on a select number of chips, the M6 is one as I hacked the driver to at least get that working. I submit that we need some sort of plan on how to get this mess resolved; I'd like to get to a state where 3D and video runs on most chips, and at least doesn't hang on the others. What I'd like to see is: + The kernel driver for the tcl-0-0 branch This gives us the best chance at API compatibility into the future as people are able to migrate to a tcl GL library, and should reduce the kernel driver churn a bit. + The video patches from XFree86 These display reasonable video on the 7500 and others. They don't currently work on the 8500, but I'll go get one of those and make them work when I've got a spare minute or two. I don't think the problems are all that hard. I'll see about stealing some bits from GATOS, but that code doesn't generally cover the hardware as completely as the XFree86 driver needs to. + The regular DRI GL bits These have some important fixes missing from the XFree86 tree while not incorporating all of the tcl changes which are probably less well tested on older Radeon cards. Keith Packard XFree86 Core Team HP Cambridge Research Lab |
|
From: Linus T. <tor...@tr...> - 2002-05-24 20:45:04
|
On Fri, 24 May 2002, Keith Packard wrote: > > I submit that we need some sort of plan on how to get this mess resolved; > I'd like to get to a state where 3D and video runs on most chips, and at > least doesn't hang on the others. What I'd like to see is: > > + The kernel driver for the tcl-0-0 branch > > This gives us the best chance at API compatibility into the future > as people are able to migrate to a tcl GL library, and should > reduce the kernel driver churn a bit. I've successfully (at least as far as I can tell) merged this into my 2.5.x tree, already available as BK patches, and I'll make a 2.5.18 release probably later today for non-BK people to enjoy. It _seems_ to be backwards-compatible (which has been a problem in the past), so it might even be possibly to merge it back into 2.4.x, but that's not my decision. In a 2.5.x timeframe, the merge was a no-brainer. > + The video patches from XFree86 > > These display reasonable video on the 7500 and others. They > don't currently work on the 8500, but I'll go get one of those > and make them work when I've got a spare minute or two. Keith, I've got an extra one you could get if actual hw access is the problem (as opposed to just time, which tends to be the biggest problem most of the time). > + The regular DRI GL bits > > These have some important fixes missing from the XFree86 tree while > not incorporating all of the tcl changes which are probably less > well tested on older Radeon cards. Now this is for somebody else to sort out, but it does sound like the DRI and XF86 would be better off trying to work together more.. There's probably not a _lot_ of overlap, so it shouldn't be painful. Linus |
|
From: F. <j_r...@ya...> - 2002-05-24 20:54:03
|
On 2002.05.24 21:45 Linus Torvalds wrote: > > On Fri, 24 May 2002, Keith Packard wrote: > > > > ... > > > + The regular DRI GL bits > > > > These have some important fixes missing from the XFree86 tree > while > > not incorporating all of the tcl changes which are probably > less > > well tested on older Radeon cards. > > Now this is for somebody else to sort out, but it does sound like the DRI > and XF86 would be better off trying to work together more.. There's > probably not a _lot_ of overlap, so it shouldn't be painful. > > Linus > Keith P., even very recentely it was discussed on the Xpert mailing list that the XFree86 project didn't have the manpower to handle all the patches that are being submited regularly. How do you propose that we channel fixes to the XFree86 CVS? (IMHO: More a reason to have bugzilla, give CVS access to more people and so on..) José Fonseca |
|
From: Linus T. <tor...@tr...> - 2002-05-24 21:05:38
|
On Fri, 24 May 2002, Jos=E9 Fonseca wrote: > > Keith P., even very recentely it was discussed on the Xpert mailing lis= t > that the XFree86 project didn't have the manpower to handle all the > patches that are being submited regularly. From personal experience, it doesn't get better, it only gets worse. Once you start falling behind, it just gets harder and harder to catch up. My personal approach for the kernel ends up just accepting when I have to trust people, and then accepting their patches and judgement with only a very high-level filter at that point. > How do you propose that we channel fixes to the XFree86 CVS? (IMHO: Mor= e > a reason to have bugzilla, give CVS access to more people and so on..) I don't personally much like CVS because it ends up being so painful to branch for small temporary projects, and I have never _ever_ seen a clean merge back, but yes, I do think that the core DRI people should just have write access to the general XF86 tree, and use _that_ as the main one (or the other way around, of course, although I have this feeling that it is politically easier to use the XF86 tree). Two separate CVS trees just does not work. CVS isn't designed to help tha= t case at all, causing just extra work for everybody. It results in merges being very occasional, and way more painful than they should be. Linus |
|
From: F. <j_r...@ya...> - 2002-05-24 22:03:28
|
On 2002.05.24 22:05 Linus Torvalds wrote: > > > On Fri, 24 May 2002, José Fonseca wrote: > > > > Keith P., even very recentely it was discussed on the Xpert mailing > list > > that the XFree86 project didn't have the manpower to handle all the > > patches that are being submited regularly. > > >From personal experience, it doesn't get better, it only gets worse. > Once > you start falling behind, it just gets harder and harder to catch up. My > personal approach for the kernel ends up just accepting when I have to > trust people, and then accepting their patches and judgement with only a > very high-level filter at that point. > > > How do you propose that we channel fixes to the XFree86 CVS? (IMHO: > More > > a reason to have bugzilla, give CVS access to more people and so on..) > > I don't personally much like CVS because it ends up being so painful to > branch for small temporary projects, and I have never _ever_ seen a clean > merge back, but yes, I do think that the core DRI people should just have > write access to the general XF86 tree, and use _that_ as the main one (or > the other way around, of course, although I have this feeling that it is > politically easier to use the XF86 tree). Not only politically reason, but the DRI CVS tree is just a partial and not a full XFree86 tree, i.e., some of the stuff is not included, and that's why it's necessary to have a matching XFree86 release installed on your system. > Two separate CVS trees just does not work. CVS isn't designed to help > that > case at all, causing just extra work for everybody. It results in merges > being very occasional, and way more painful than they should be. You're not trying to sell a widely known and rather polemical piece of software, are you? ;-) Seriously, the DRI stuff does live in seperate directories, with the sole exception of the 2D driver, many of which have different maintainers in the XFree86 project scope. So there is a strong physical seperation of the DRI code in the XFree86 tree. So, more than the time that takes to merge trees, it would be the sinergy of both projects. (My primarily concern is that the lack of manpower and tight policies of the XFree86 project would drag us down instead of boosting). José Fonseca |
|
From: Keith P. <ke...@ke...> - 2002-05-24 20:54:56
|
Around 13 o'clock on May 24, Linus Torvalds wrote: > Keith, I've got an extra one you could get if actual hw access is the > problem (as opposed to just time, which tends to be the biggest problem > most of the time). I've got a stack of video cards; I can manage to get another, and I think I'll have some spare time just after Usenix. I got a bit behind in releasing Xft2 and fontconfig and am attempting to catch up this week. I do have Qt3 patches for Xft2 if you're interested in giving those a whirl... (http://keithp.com/fonts) > Now this is for somebody else to sort out, but it does sound like the DRI > and XF86 would be better off trying to work together more.. There's > probably not a _lot_ of overlap, so it shouldn't be painful. We have an agreement in principle for DRI to use the XFree86 CVS tree instead of their separate tree on sourceforge, but that hasn't happened for reasons I don't understand. While that won't fix everything, it should help keep the two main development branches going in the same direction. Keith Packard XFree86 Core Team HP Cambridge Research Lab |
|
From: David D. <dawes@XFree86.Org> - 2002-05-26 17:22:58
|
On Fri, May 24, 2002 at 01:54:52PM -0700, Keith Packard wrote: >We have an agreement in principle for DRI to use the XFree86 CVS tree >instead of their separate tree on sourceforge, but that hasn't happened >for reasons I don't understand. While that won't fix everything, it I think that's overstating it. Several people have agreed at various times that it would be a good idea, but that isn't the same as both groups agreeing to merge their development trees. The DRI project and its various sub-projects have different goals, development cycles and models to XFree86, and I don't see any good reasons to force either project into the other's model. The branch-based development model is different, as is the CVS commit access policy. It's largely because of a difference in development cycles, for example, that the current XFree86 trunk hasn't been merged in yet. The current DRI development is intended to be usable with XFree86 4.2 rather than requiring the current XFree86 development stuff. Things like this mean that what is now the DRI trunk would be a branch within the XFree86 CVS anyway. From my experience with many DRI<->XFree86 merges, the level of effort required isn't much different than for branches within a single CVS. One reason for this is that the XFree86 trunk is a (vendor) branch in the DRI CVS, so with the exception of the import phase (which is a no-brainer), it boils down to a branch merge either way. As for moving code in both directions, there are 3 people with commit access in both places and who have experience with CVS merges and the DRI code. The only reason why the DRI and XFree86 CVS repositories are as diverged as at present is their different positions within their development cycle. When the DRI developers are ready to work with code closer to the XFree86 trunk than to XFree86 4.2, that resync will happen. I don't think this is impeding DRI development progress, but it if is, someone should let me know. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes |
|
From: Alan H. <al...@fa...> - 2002-05-27 10:53:58
|
On Sun, May 26, 2002 at 01:22:46PM -0400, David Dawes wrote: > On Fri, May 24, 2002 at 01:54:52PM -0700, Keith Packard wrote: > > >We have an agreement in principle for DRI to use the XFree86 CVS tree > >instead of their separate tree on sourceforge, but that hasn't happened > >for reasons I don't understand. While that won't fix everything, it > > I think that's overstating it. Several people have agreed at > various times that it would be a good idea, but that isn't the same > as both groups agreeing to merge their development trees. > > The DRI project and its various sub-projects have different goals, > development cycles and models to XFree86, and I don't see any good > reasons to force either project into the other's model. The > branch-based development model is different, as is the CVS commit > access policy. It's largely because of a difference in development > cycles, for example, that the current XFree86 trunk hasn't been > merged in yet. The current DRI development is intended to be usable > with XFree86 4.2 rather than requiring the current XFree86 development > stuff. Things like this mean that what is now the DRI trunk would > be a branch within the XFree86 CVS anyway. From my experience with > many DRI<->XFree86 merges, the level of effort required isn't much > different than for branches within a single CVS. One reason for > this is that the XFree86 trunk is a (vendor) branch in the DRI CVS, > so with the exception of the import phase (which is a no-brainer), > it boils down to a branch merge either way. > > As for moving code in both directions, there are 3 people with > commit access in both places and who have experience with CVS merges > and the DRI code. The only reason why the DRI and XFree86 CVS > repositories are as diverged as at present is their different > positions within their development cycle. When the DRI developers > are ready to work with code closer to the XFree86 trunk than to > XFree86 4.2, that resync will happen. I don't think this is impeding > DRI development progress, but it if is, someone should let me know. Agreed on all counts David. Alan. |
|
From: roussel j. <ro...@en...> - 2002-05-27 13:53:25
|
Hello I am translating the DRI FAQ in french and I am trying do correct it or simplify it. I don't really understand why there is 2 parts on Mesa: one on Mesa 3.4 and one on 4.x because there are very similar. I don't really see what are the differences because it is too long. It would be better to point out the differences instead of rewriting twice the same things. Maybe I am wrong, thanks Roussel Jérôme. |
|
From: F. <j_r...@ya...> - 2002-05-27 14:24:29
|
On 2002.05.27 14:53 roussel jerome wrote: > Hello > > > I am translating the DRI FAQ in french and I am trying do correct it or > simplify it. I don't really understand why there is 2 parts on Mesa: one > on Mesa 3.4 and one on 4.x because there are very similar. I don't > really see what are the differences because it is too long. It would be > better to point out the differences instead of rewriting twice the same > things. He! He! They are different, believe me - me and Leif spend a week together to port a driver from 3.4 to 4.x! The world wasn't made in one day: first there was Mesa 3.4 internal docs, then it was adapted to Mesa 4.x. Mesa 3.4 is deprecated now, but I left it there because there are some drivers which weren't ported to Mesa 4.x yet (both in DRI as in Utah GLX). But I'd rather delete it than loosing time to explain the differences. > Maybe I am wrong, > > thanks > > Roussel Jérôme. My advice is to ignore the 3.x stuff. I'll eventually delete it too. If someone eventually needs it one can always get a older version of the FAQ in the CVS repository. I look forward to see the French version of the FAQ ;-) Regards, José Fonseca |
|
From: Ian M. <sp...@ar...> - 2002-05-27 17:10:19
|
On Mon, 27 May 2002 15:53:49 +0200 roussel jerome <ro...@en...> wrote: > > I am translating the DRI FAQ in french and I am trying do correct it > or simplify it. Do bear in mind that I am re-doing the website. I will accept any other translations of documents you wish to do also. |
|
From: roussel j. <ro...@en...> - 2002-05-27 17:36:29
|
Ian Molton wrote: >On Mon, 27 May 2002 15:53:49 +0200 >roussel jerome <ro...@en...> wrote: > >>I am translating the DRI FAQ in french and I am trying do correct it >>or simplify it. >> > >Do bear in mind that I am re-doing the website. > >I will accept any other translations of documents you wish to do also. > Thanks. It takes a lot of time so I don't know if I will have the time to translate any other docs because I do this without any software. Do you know some softwares to translate docbook docs??? For the time being, I have also an general overview in French but it doesn't add anything to the actual docs. I will change it a little and I will send it to you but you will have to wait a few weeks... I am not an expert with docbook (and I do this in my spare time, I am a student in Telecom in Paris) so if someone wants to help me with the formatting of the files (with the different output), I would be pleased. Thanks, Roussel Jérôme. |
|
From: Keith W. <ke...@tu...> - 2002-05-24 23:57:07
|
Linus Torvalds wrote: > > On Fri, 24 May 2002, Keith Packard wrote: > >>I submit that we need some sort of plan on how to get this mess resolved; >>I'd like to get to a state where 3D and video runs on most chips, and at >>least doesn't hang on the others. What I'd like to see is: >> >>+ The kernel driver for the tcl-0-0 branch >> >> This gives us the best chance at API compatibility into the future >> as people are able to migrate to a tcl GL library, and should >> reduce the kernel driver churn a bit. >> > > I've successfully (at least as far as I can tell) merged this into my > 2.5.x tree, already available as BK patches, and I'll make a 2.5.18 > release probably later today for non-BK people to enjoy. > > It _seems_ to be backwards-compatible (which has been a problem in the > past), so it might even be possibly to merge it back into 2.4.x, but > that's not my decision. In a 2.5.x timeframe, the merge was a no-brainer. Linus, as this constitues a defacto release of code it's probably good to know about it when this happens... It's not a problem, but it does mark a point at which the new interfaces become public, and it's happened in a different order than the normally circuitous DRI release plan (dri-branch-->dri-trunk-->xfree-->kernel--> redhat-->user). Not that that's a bad thing as the card usually eols about halfway through that... We've made a lot of effort to improve our awareness of backwards compatibility issues and I've done a fair bit of testing there. The story doesn't really end with kernel backwards compatibility as there's no real way of saying which component (XFree-core,kernel,2d-driver,3d-driver) a user is more or less likely to upgrade than any other. We're now committed to having at 3d available and accelerated to the best ability of the combination of these components installed on any given system. Any failures due to compatibility issues that come up can hopefully be treated as coding rather than philosophical bugs. Keith And yes, I also would be very happy to see DRI cvs go away in favour of XFree86. |
|
From: Linus T. <tor...@tr...> - 2002-05-25 00:04:13
|
On Sat, 25 May 2002, Keith Whitwell wrote: > > Linus, as this constitues a defacto release of code it's probably good to know > about it when this happens... > > It's not a problem, but it does mark a point at which the new interfaces > become public, and it's happened in a different order than the normally > circuitous DRI release plan (dri-branch-->dri-trunk-->xfree-->kernel--> > redhat-->user). Not that that's a bad thing as the card usually eols about > halfway through that... Note that the development tree often has new interfaces that change over time, so people should _not_ feel too bound to be binary compatible. In fact, just the other day the new "fast mutex" primitives in 2.5.x got updated to totally different semantics that allowed for much a wider variety of behaviour. It's when something gets close to a stable release (either backwards or forwards) that binary competibility becomes an issue. Exactly like with XFree86 itself. But yes, it does add some amount of synchronization points. Linus |
|
From: Keith W. <ke...@tu...> - 2002-05-25 00:10:17
|
Linus Torvalds wrote: > > On Sat, 25 May 2002, Keith Whitwell wrote: > >>Linus, as this constitues a defacto release of code it's probably good to know >>about it when this happens... >> >>It's not a problem, but it does mark a point at which the new interfaces >>become public, and it's happened in a different order than the normally >>circuitous DRI release plan (dri-branch-->dri-trunk-->xfree-->kernel--> >>redhat-->user). Not that that's a bad thing as the card usually eols about >>halfway through that... >> > > Note that the development tree often has new interfaces that change over > time, so people should _not_ feel too bound to be binary compatible. In > fact, just the other day the new "fast mutex" primitives in 2.5.x got > updated to totally different semantics that allowed for much a wider > variety of behaviour. > > It's when something gets close to a stable release (either backwards or > forwards) that binary competibility becomes an issue. Exactly like with > XFree86 itself. OK, fair enough. There weren't any binary-incompatible changes planned or forseen for the new code on the branch in any case - I've just gotten lazy about finishing that development cycle off & getting it onto the trunk. Keith |
Thanks for helping keep SourceForge clean.
X