RE: [Xpert]KDE3/i810 corruption - source pointers?
On Thu, 26 Sep 2002, Neale Banks wrote: Ah, that's interesting. A few of us have been plagued by a crash which happens with i810 when running two servers - and goes away when XaaNoSolidFillRect is set on. Ah, according to the README file in the driver directory: 7. Known Limitations - No 32bpp support in this driver. - Running Two Xservers on different VT's is not supported at this time. Any chance that these two problems are different manifestations of the same coding oversight? The operations you listed are two entirely different blitter instructions (SRC_COPY_BLT as opposed to COLOR_BLT). You're correct in that the code to stuff the instruction into the ring buffer is very similar, but in the first case (SRC_COPY_BLT), the 5th parameter is a 14 bit source pitch, while in the second case (COLOR_BLT), the 5th parameter is a 24 bit color. If so, what would be the correct constructs here? For the SRC_COPY_BLT, the correct code would be: OUT_RING( pI810-BR[13] 0x3FFF ); i.e. masking the value to 14 bits instead of 16. Matt had said this probaly isn't a big deal, though. Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Sottek, Matthew J wrote: No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. I've posted a few example pics of the corruption I see: http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted menubar http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of corruption The corrupted regions are 14x22, with the exception of the one above 'hours'. Each region is a well-formed horizontal gradient (!). If the pitch was off while blitting from pixmap cache to framebuffer, wouldn't the corruption just be garbage? And a width of 14 seems like a really odd size for a blit to me. Maybe the problem then isn't with the blit from the pixmap cache to the framebuffer, but it's that the pixmap cache itself is getting corrupted? Jeff's memory management patch is looking fairly attractive. Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers?
There was some discussion of this problem on this list a while back. There is a separate set of overlay-fb alignment registers that are programmed relative to the timings being used. When you boot to a TV device the timings are not as programmed in the CRTC registers so the overlay is not properly aligned. The vBois put the timings in the TV timings regs and it is different depending on the 3rd part TV encoder used on your system. I thought that someone had provided a fix that programmed that register by looking at the TV timings (If the TV was being used) The register is called OVRACT, you may want to search the archives for some discussion of that register. -Matt -Original Message- From: Sebastien BASTARD [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 12:46 AM To: [EMAIL PROTECTED] Subject: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers? Hello, When i use xine to see the film in Xv mode, I have the screen film shift on the left (everage 16 pixels). If i set the resolution to 800x600, i have a blue screen (color_key). Is it the same problem about you talk when i use the Xv ouput on i810 ? Configuration : - XFree 4.2.1 - i810 - Resolution : 640x480x24 Thanks for all [EMAIL PROTECTED] 26/09/2002 00:07 Hola, This is just a hunch but I'm wondering if this could be a previously undetected problem in the XFree86 memory manager. I want you people who can reproduce the problem to try the above patch and tell me if it works. I unfortunately no longer have access to an i810 or i815 (or i830 or i845 for that matter.) So I can't test this to see if it works. If it does there is a problem with the memory manager using the leftover bit of memory on the side of the screen. Its probably very rare to hit the path and probably just a small calculation thats off somewhere. If this patch works it gives you a good data point at any rate, one thing which is not causing the problem. You might also try building the i810 driver with the #define XF86DRI not defined because that will make the pitch and the width always be the same. That will give you an additional data point to help you track down the problem. -Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
Bill Soudan writes: On Wed, 25 Sep 2002, Sottek, Matthew J wrote: No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. I've posted a few example pics of the corruption I see: http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted menubar http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of corruption The corrupted regions are 14x22, with the exception of the one above 'hours'. Each region is a well-formed horizontal gradient (!). If the pitch was off while blitting from pixmap cache to framebuffer, wouldn't the corruption just be garbage? And a width of 14 seems like a really odd size for a blit to me. Maybe the problem then isn't with the blit from the pixmap cache to the framebuffer, but it's that the pixmap cache itself is getting corrupted? Jeff's memory management patch is looking fairly attractive. The XAA code uses ScreenToScreenCopy to create a background pixmap in offscreen memory out of the elemantary tile. In KDE the backgrounds of the menu bars are created this way. When a menu bar needs to be redrawn XAA simply copies a portion from this offscreen pixmap into the framebuffer. Now the problem: The i810 blit engine seems to be broken in that it cannot copy a portion of the framebuffer right to the right of itself if the width of this area is in a certain range. I found that out by trial and error as Intel appearantly doesn't provide errata sheets. I've attempted to make a fix for this which I will soon commit to CVS. I don't know it it catches all cases however the KDE desktop on my test machine appears to be uncorrupted now. Your milage may vary. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Fri, 27 Sep 2002, Egbert Eich wrote: Now the problem: The i810 blit engine seems to be broken in that it cannot copy a portion of the framebuffer right to the right of itself if the width of this area is in a certain range. Even if the source destination regions don't overlap? That sounds surprisingly broken. The problem is very intermittent on my machine. Once it happens, though, the corruption sticks around for a while. Filling up my display with konqueror windows pointed to different websites is the most reliable way I've found to trigger the bug, and likewise, closing windows and freeing resources in general seems to make it go away. Could this be explained by XAA generating blit requests for this buggy width during the times I experience the corruption? I found that out by trial and error as Intel appearantly doesn't provide errata sheets. I've attempted to make a fix for this which I will soon commit to CVS. I don't know it it catches all cases however the KDE desktop on my test machine appears to be uncorrupted now. Your milage may vary. What sort of workaround did you put in? I'd be happy to give the patch a shot if you'd like to send it this way. I did find an errata pdf on Intel's website alongside the specs, and it even lists a blitter bug, but I ignored it as it didn't sound relevant. Still doesn't, apparently a few pixels at the end of each scanline get skewed. Certainly shouldn't corrupt a vertical gradient, in any case. Thanks, Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
Removing the define causes the code not to attempt to align the framebuffer to pitches compatible with 3D acceleration. With that define the i810 driver attempts to make sure the framebuffer pitch is one that is compatible with 3d acceleration. The i810 can use any pitch, but normally chooses one that is DRI compatible if the dri is compiled in. -Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers?
Hello, When i use xine to see the film in Xv mode, I have the screen film shift on the left (everage 16 pixels). If i set the resolution to 800x600, i have a blue screen (color_key). Is it the same problem about you talk when i use the Xv ouput on i810 ? Configuration : - XFree 4.2.1 - i810 - Resolution : 640x480x24 Thanks for all [EMAIL PROTECTED] 26/09/2002 00:07 Hola, This is just a hunch but I'm wondering if this could be a previously undetected problem in the XFree86 memory manager. I want you people who can reproduce the problem to try the above patch and tell me if it works. I unfortunately no longer have access to an i810 or i815 (or i830 or i845 for that matter.) So I can't test this to see if it works. If it does there is a problem with the memory manager using the leftover bit of memory on the side of the screen. Its probably very rare to hit the path and probably just a small calculation thats off somewhere. If this patch works it gives you a good data point at any rate, one thing which is not causing the problem. You might also try building the i810 driver with the #define XF86DRI not defined because that will make the pitch and the width always be the same. That will give you an additional data point to help you track down the problem. -Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Bill Soudan wrote: http://www.xfree86.org/pipermail/xpert/2002-June/018208.html Why changing the resolution to 24bpp 'solves' the problem: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_accel.c: /* There is a bit blt bug in 24 bpp. This is a problem, but at least without the pixmap cache we can pass the test suite */ if(pScrn-depth != 24) infoPtr-Flags |= PIXMAP_CACHE; I believe this indicates to the Xserver that the driver can't do a pixmap cache, which has the same effect as enabling the XaaNoPixmapCache flag. Maybe this is actually a hardware bug then (ugh)? More pronounced at 24bpp but still exists at the other depths? Maybe I'll remove the check and try 24bpp with a pixmap cache just to see what happens... Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
I don't think there are any issues with the blit engine at 16 bit. I think the problem has something to do with the way multi-line pixmap cache's are stored in the offscreen memory. The pitch in the Xaa functions is set to be the same pitch as the framebuffer, which may not be the case. If you can track down the code that puts the cached pixmaps in the offscreen memory you can probably determine how they are being arranged in that memory. Perhaps that code is unaware of the pitch != width case. (Is Xaa used to blit from on-screen locations to the offscreen cache?) -Matt -Original Message- From: Bill Soudan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 9:42 AM To: [EMAIL PROTECTED] Subject: Re: [Xpert]KDE3/i810 corruption - source pointers? On Wed, 25 Sep 2002, Bill Soudan wrote: http://www.xfree86.org/pipermail/xpert/2002-June/018208.html Why changing the resolution to 24bpp 'solves' the problem: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_accel.c: /* There is a bit blt bug in 24 bpp. This is a problem, but at least without the pixmap cache we can pass the test suite */ if(pScrn-depth != 24) infoPtr-Flags |= PIXMAP_CACHE; I believe this indicates to the Xserver that the driver can't do a pixmap cache, which has the same effect as enabling the XaaNoPixmapCache flag. Maybe this is actually a hardware bug then (ugh)? More pronounced at 24bpp but still exists at the other depths? Maybe I'll remove the check and try 24bpp with a pixmap cache just to see what happens... Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Sottek, Matthew J wrote: I don't think there are any issues with the blit engine at 16 bit. Is there an i810 blitter bug at 24bpp? (and that's what the author of the code was referring to?) I think the problem has something to do with the way multi-line pixmap cache's are stored in the offscreen memory. The pitch in the Xaa functions is set to be the same pitch as the framebuffer, which may not be the case. If you can track down the code that puts the cached pixmaps in the offscreen memory you can probably determine how they are being arranged in that memory. Perhaps that code is unaware of the pitch != width case. (Is Xaa used to blit from on-screen locations to the offscreen cache?) I did notice the source destination pitches in the blitter instruction are explicity set to the same value. I'll see if I can track down the code that stores the pixmaps in offscreen memory. I can't answer your question about Xaa yet, either. But if your theory is correct, and the source pitch was wildly incorrect, wouldn't nearly all blits be corrupted? For me at least, the problem is intermittent. Right now my display is fine. A few moments ago when I was browsing the i810 specs the corruption appeared and I was able to try a few experiments: 1) If I cover a corrupted section of the display with a window, then minimize it, the corruption is still there. 2) If I slowly drag a window over a corrupted section of a different window horizontally, the corruption is erased. (!) 3) If I slowly drag a window over a corrupted section of a different window vertically, the corruption is redrawn. 4) ... diagonally, the corruption is erased along the trailing horizontal edge, and worsened (!) along the trailing vertical edge. The resulting corruption on the vertical edge is much more severe than I normally see. I'm not sure what the trigger is for the corruption to appear though, nor have I figured out what causes it to go away. One silly thing I noticed is that the code used to write the blitter source pitch to the ring buffer in I810SubsequentScreenToScreenCopy: OUT_RING( pI810-BR[13] 0x ); should really only write 13 bits, 14-32 are reserved according to my copy of the specs. Does the i810 get cranky about its reserved bits? Thanks for the input, Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
Hola, This is just a hunch but I'm wondering if this could be a previously undetected problem in the XFree86 memory manager. I want you people who can reproduce the problem to try the above patch and tell me if it works. I unfortunately no longer have access to an i810 or i815 (or i830 or i845 for that matter.) So I can't test this to see if it works. If it does there is a problem with the memory manager using the leftover bit of memory on the side of the screen. Its probably very rare to hit the path and probably just a small calculation thats off somewhere. If this patch works it gives you a good data point at any rate, one thing which is not causing the problem. You might also try building the i810 driver with the #define XF86DRI not defined because that will make the pitch and the width always be the same. That will give you an additional data point to help you track down the problem. -Jeff i810.diff Description: Binary data
RE: [Xpert]KDE3/i810 corruption - source pointers?
I don't think there are any issues with the blit engine at 16 bit. Is there an i810 blitter bug at 24bpp? (and that's what the author of the code was referring to?) Yes, I believe there is a 24bpp problem. Most of the i810 only runs at 16bit so the normal use case has always been 16bit. But if your theory is correct, and the source pitch was wildly incorrect, wouldn't nearly all blits be corrupted? No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. One silly thing I noticed is that the code used to write the blitter source pitch to the ring buffer in I810SubsequentScreenToScreenCopy: OUT_RING( pI810-BR[13] 0x ); should really only write 13 bits, 14-32 are reserved according to my copy of the specs. Does the i810 get cranky about its reserved bits? That isn't a problem. Bits like that are usually reserved to make room for larger values in possible future chipsets without having to move bits around. I'm sure it is fine. I checked the code again and I'm still thinking the problem is with the data getting stored into the cache. That seems to be in the Xaa code, not the i810 code so it is possible that the pitches are not in sync. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
[Note Cc's to potentially interested parties added - Neale]
On Wed, 25 Sep 2002, Bill Soudan wrote:
[...]
One silly thing I noticed is that the code used to write the blitter
source pitch to the ring buffer in I810SubsequentScreenToScreenCopy:
OUT_RING( pI810-BR[13] 0x );
should really only write 13 bits, 14-32 are reserved according to my copy
of the specs. Does the i810 get cranky about its reserved bits?
Ah, that's interesting. A few of us have been plagued by a crash which
happens with i810 when running two servers - and goes away when
XaaNoSolidFillRect is set on. In
i810_accel.c:I810SubsequentSolidFillRect() we find:
OUT_RING( pI810-BR[13] );
and
OUT_RING( pI810-BR[16]);
Hmm... similar code fragments...
I810SubsequentScreenToScreenCopy():
===8===
{
BEGIN_LP_RING(6);
OUT_RING( BR00_BITBLT_CLIENT | BR00_OP_SRC_COPY_BLT | 0x4 );
OUT_RING( pI810-BR[13] );
OUT_RING( (h 16) | (w * pI810-cpp));
OUT_RING( pI810-bufferOffset + dst );
OUT_RING( pI810-BR[13] 0x );
OUT_RING( pI810-bufferOffset + src );
ADVANCE_LP_RING();
}
===8===
I810SubsequentSolidFillRect():
===8===
{
BEGIN_LP_RING(6);
OUT_RING( BR00_BITBLT_CLIENT | BR00_OP_COLOR_BLT | 0x3 );
OUT_RING( pI810-BR[13] );
OUT_RING( (h 16) | (w * pI810-cpp));
OUT_RING( pI810-bufferOffset +
(y * pScrn-displayWidth + x) * pI810-cpp);
OUT_RING( pI810-BR[16]);
OUT_RING( 0 );/* pad to quadword */
ADVANCE_LP_RING();
}
===8===
Any chance that these two problems are different manifestations of the
same coding oversight?
If so, what would be the correct constructs here?
Thanks,
Neale.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Jeff Hartmann wrote: This is just a hunch but I'm wondering if this could be a previously undetected problem in the XFree86 memory manager. I want you people who can reproduce the problem to try the above patch and tell me if it works. I unfortunately no longer have access to an i810 or i815 (or i830 or i845 for that matter.) So I can't test this to see if it works. If it does there is a problem with the memory manager using the leftover bit of memory on the side of the screen. Its probably very rare to hit the path and probably just a small calculation thats off somewhere. If this patch works it gives you a good data point at any rate, one thing which is not causing the problem. Thanks for the patch - I'll give it a shot and let you know the result. I'm going to try to find a reliable way to reproduce the corruption tomorrow. You might also try building the i810 driver with the #define XF86DRI not defined because that will make the pitch and the width always be the same. That will give you an additional data point to help you track down the problem. I believe it's already been determined this gets rid of the problem - I haven't tried this myself, yet, but according to the past email threads the bug isn't present at 1024x768 where width == pitch. Just to make sure I'm understanding the concepts of pitch width correctly: framebuffer width - number of bytes in memory that map to one scanline as displayed on the screen pitch - byte offset in memory between scanlines Why does removing the XF86DRI define ensure they're always equal? And for what reasons will they be different (I'm assuming maybe some sort of alignment comes into play here?)? Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Sottek, Matthew J wrote: But if your theory is correct, and the source pitch was wildly incorrect, wouldn't nearly all blits be corrupted? No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. Sorry, I should have qualified - I did mean all blits from the pixmap cache to the framebuffer. I know one of the big features of KDE's theming support was that it takes advantage of X's pixmap cache, so I would assume most of the blits are pixmap cache - framebuffer? That isn't a problem. Bits like that are usually reserved to make room for larger values in possible future chipsets without having to move bits around. I'm sure it is fine. I figured, but just thought I'd check. I've dealt with hardware in the past that got really upset when you started poking at its reserved bits... I checked the code again and I'm still thinking the problem is with the data getting stored into the cache. That seems to be in the Xaa code, not the i810 code so it is possible that the pitches are not in sync. I'll try to locate the Xaa pixmap code tomorrow. Thanks, Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
