From: Linus T. <tor...@tr...> - 2003-03-30 06:48:34
|
I just finished a merge of the current DRI CVS tree kernel parts into 2.5.x. I've not done one of these in a while, so sadly the merge ends up being several totally unrelated things (i830 irq updates, the lock context fixes, and various random smaller things). I've pushed the result out, and it should show up in the next nightly snapshot (and earlier, if you'r ea BK user or follow the patch-list). If somebody in the DRI group would double-check, that would be good. I tested on radeon, and tested by compiling all the drivers into the kernel. Looked good as far as I can tell. Although I have to say that the current DRI CVS tree has a lot of flashing textures on the commercial tuxracer thing. Last I tested - a long time ago - the "texmem" branch was picture-perfect and performed better too. In contrast, no CVS head has ever had correct textures on tuxracer for me (although the flashing behaviour seems to change occasionally). Btw, here's a few spelling fixes for the DRI tree - if somebody can apply them I don't have to be careful about trying to not revert fixes in the kernel when I try to merge next time. Linus ---- diff -u --recursive --exclude='*C*S' dri-kernel/drm_vm.h v2.5/linux/drivers/char/drm/drm_vm.h --- dri-kernel/drm_vm.h 2002-12-13 13:15:13.000000000 -0800 +++ v2.5/linux/drivers/char/drm/drm_vm.h 2003-03-26 09:10:13.000000000 -0800 @@ -147,7 +146,7 @@ } /* Special close routine which deletes map information if we are the last - * person to close a mapping and its not in the global maplist. + * person to close a mapping and it's not in the global maplist. */ void DRM(vm_shm_close)(struct vm_area_struct *vma) diff -u --recursive --exclude='*C*S' dri-kernel/i810_drm.h v2.5/linux/drivers/char/drm/i810_drm.h --- dri-kernel/i810_drm.h 2002-06-12 09:55:13.000000000 -0700 +++ v2.5/linux/drivers/char/drm/i810_drm.h 2003-03-26 09:10:13.000000000 -0800 @@ -38,7 +38,7 @@ * - zbuffer linear offset and pitch -- also invarient * - drawing origin in back and depth buffers. * - * Keep the depth/back buffer state here to acommodate private buffers + * Keep the depth/back buffer state here to accommodate private buffers * in the future. */ #define I810_DESTREG_DI0 0 /* CMD_OP_DESTBUFFER_INFO (2 dwords) */ diff -u --recursive --exclude='*C*S' dri-kernel/i830_dma.c v2.5/linux/drivers/char/drm/i830_dma.c --- dri-kernel/i830_dma.c 2003-03-29 20:52:39.000000000 -0800 +++ v2.5/linux/drivers/char/drm/i830_dma.c 2003-03-29 22:38:01.000000000 -0800 @@ -439,7 +432,7 @@ DRM_DEBUG("pitch_bits %x\n", init->pitch_bits); dev_priv->cpp = init->cpp; - /* We are using seperate values as placeholders for mechanisms for + /* We are using separate values as placeholders for mechanisms for * private backbuffer/depthbuffer usage. */ diff -u --recursive --exclude='*C*S' dri-kernel/i830_drm.h v2.5/linux/drivers/char/drm/i830_drm.h --- dri-kernel/i830_drm.h 2003-03-29 20:52:39.000000000 -0800 +++ v2.5/linux/drivers/char/drm/i830_drm.h 2003-03-29 22:38:01.000000000 -0800 @@ -70,7 +70,7 @@ * - zbuffer linear offset and pitch -- also invarient * - drawing origin in back and depth buffers. * - * Keep the depth/back buffer state here to acommodate private buffers + * Keep the depth/back buffer state here to accommodate private buffers * in the future. */ |
From: Keith W. <ke...@tu...> - 2003-03-30 08:20:17
|
Linus Torvalds wrote: > I just finished a merge of the current DRI CVS tree kernel parts into > 2.5.x. I've not done one of these in a while, so sadly the merge ends up > being several totally unrelated things (i830 irq updates, the lock context > fixes, and various random smaller things). > > I've pushed the result out, and it should show up in the next nightly > snapshot (and earlier, if you'r ea BK user or follow the patch-list). If > somebody in the DRI group would double-check, that would be good. > > I tested on radeon, and tested by compiling all the drivers into the > kernel. Looked good as far as I can tell. Although I have to say that the > current DRI CVS tree has a lot of flashing textures on the commercial > tuxracer thing. Last I tested - a long time ago - the "texmem" branch was > picture-perfect and performed better too. In contrast, no CVS head has > ever had correct textures on tuxracer for me (although the flashing > behaviour seems to change occasionally). > > Btw, here's a few spelling fixes for the DRI tree - if somebody can apply > them I don't have to be careful about trying to not revert fixes in the > kernel when I try to merge next time. Looks like Eric beat me to it... Anyway, thanks, Linus. The plan is to merge texmem asap, so with luck you'll see an improvement on the trunk as a result of that. Keith |
From: Linus T. <tor...@tr...> - 2003-03-30 17:47:31
|
On Sat, 29 Mar 2003, Linus Torvalds wrote: > > I tested on radeon, and tested by compiling all the drivers into the > kernel. Looked good as far as I can tell. Although I have to say that the > current DRI CVS tree has a lot of flashing textures on the commercial > tuxracer thing. I also checked it out on a i845GE setup, and it has occasional flashes there too, much much less. However, more worrying is that the current DRI tree seems to (a) break Xscreensaver (yeah yeah, I saw the flames, but it's still annoying from a _user_ perspective) and (b) after 5 minutes of testing on the i845GE thing I already saw what appeared to be a hard lockup on server restart. I had thought people reported the server restart thing as fixed? It didn't look that way to me. Linus |
From: Keith W. <ke...@tu...> - 2003-03-30 18:36:54
|
Linus Torvalds wrote: > On Sat, 29 Mar 2003, Linus Torvalds wrote: > >>I tested on radeon, and tested by compiling all the drivers into the >>kernel. Looked good as far as I can tell. Although I have to say that the >>current DRI CVS tree has a lot of flashing textures on the commercial >>tuxracer thing. > > > I also checked it out on a i845GE setup, and it has occasional flashes > there too, much much less. > > However, more worrying is that the current DRI tree seems to (a) break > Xscreensaver (yeah yeah, I saw the flames, but it's still annoying from a > _user_ perspective) and (b) after 5 minutes of testing on the i845GE thing > I already saw what appeared to be a hard lockup on server restart. > I had thought people reported the server restart thing as fixed? It didn't > look that way to me. The server reset bug that was fixed was radeon-specific. I've been trying with the dri trunk & can't reproduce the hang on one 845 box, though I've got another & can try that too. Keith |
From: Linus T. <tor...@tr...> - 2003-03-30 19:15:05
|
On Sun, 30 Mar 2003, Keith Whitwell wrote: > > The server reset bug that was fixed was radeon-specific. I've been trying > with the dri trunk & can't reproduce the hang on one 845 box, though I've got > another & can try that too. Ok. I've tried to figure out what triggers it - it doesn't always happen. It does seem to happen when restarting the X server after having played the commercial tuxracer (I'm setting up a box for my 6-year-old, so for once I'm not playing tuxracer just to test 3D - I actually want to have it work ;) I can sometimes restart several times, sometimes not. And I also noticed another strange thing - sometimes tuxracer works absolutely beautifully (no visual artifacts at all), and then I quit and restart, and it seems to fall back to sw rendering for some things (one frame per every two seconds) _and_ there are some obvious visual artifacts on the pink lady penguin when you select her as the racer. At least the last time I locked the machine up, it happened after the artifacts started showing. I have this feeling that it happens more often when I play windowed (as opposed to full-screen), and switch between the two, but that might just be my imagination. But yeah, this looks different from the radeon lockup. For one thing, it somtimes locks up at X restart after it has painted the desktop and is bringing up the window manager. Sometimes it locks with a black screen. And that tuxracer sw-fallback behaviour never happened with the radeon. Linus |
From: Keith W. <ke...@tu...> - 2003-04-09 11:25:29
|
Linus Torvalds wrote: > On Sun, 30 Mar 2003, Keith Whitwell wrote: > >>The server reset bug that was fixed was radeon-specific. I've been trying >>with the dri trunk & can't reproduce the hang on one 845 box, though I've got >>another & can try that too. > > > Ok. I've tried to figure out what triggers it - it doesn't always happen. > > It does seem to happen when restarting the X server after having played > the commercial tuxracer (I'm setting up a box for my 6-year-old, so for > once I'm not playing tuxracer just to test 3D - I actually want to have it > work ;) I still haven't seen the lockup, but I've managed to make tuxracer (the downloadable demo of the commercial version) look a lot more correct on my 845 box. I'll keep looking at it as spare time allows. Keith |
From: Linus T. <tor...@tr...> - 2003-03-30 19:22:09
|
On Sun, 30 Mar 2003, Keith Whitwell wrote: > > The server reset bug that was fixed was radeon-specific. I've been trying > with the dri trunk & can't reproduce the hang on one 845 box, though I've got > another & can try that too. In case you care, this is a shuttle mini-pc: 00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 03) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown device fb50 Flags: bus master, fast devsel, latency 0 Memory at e8000000 (32-bit, prefetchable) [size=64M] Capabilities: <available only to root> 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 03) (prog-if 00 [VGA]) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown device fb50 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at e0000000 (32-bit, prefetchable) [size=128M] Memory at ec100000 (32-bit, non-prefetchable) [size=512K] Capabilities: <available only to root> and I also get mtrr: base(0xe0020000) is not aligned on a size(0x300000) boundary where the 3MB mtrr thing seems to match the frame buffer address: (II) I810(0): [drm] created "i830" driver at busid "PCI:0:2:0" (II) I810(0): [drm] added 8192 byte SAREA at 0xe0124000 (II) I810(0): [drm] mapped SAREA 0xe0124000 to 0x40015000 (II) I810(0): [drm] framebuffer handle = 0xe0020000 (II) I810(0): [drm] added 1 reserved context for kernel (II) I810(0): Allocated 3072 kB for the back buffer at 0x7800000. (II) I810(0): Allocated 3072 kB for the depth buffer at 0x7400000. (II) I810(0): Allocated 32 kB for the logical context at 0x73f8000. (II) I810(0): Allocated 1024 kB for the DMA buffers at 0x72f8000. (II) I810(0): Allocated 3840 kB for textures at 0xffc40000 I don't know why it wants to cover only 3MB, since I assume it really should cover the whole 8MB area. Whatever. Linus |