On Wed, 06 Oct 2004 15:22:08 -0500, Steve Holland <[EMAIL PROTECTED]> wrote: > Your fix works! > Thanks, Alex. > >
Sounds good. I'll commit the fix tonight and make sure it doesn't break savage4. Alex > > > On Tue, 2004-10-05 at 14:20, Alex Deucher wrote: > > On Tue, 5 Oct 2004 15:07:22 -0400, Alex Deucher <[EMAIL PROTECTED]> wrote: > > > On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland <[EMAIL PROTECTED]> wrote: > > > > I downloaded the latest savage and common snapshots today, and I have a > > > > few notes (thanks for the great work!): > > > > - The snapshots do not work out-of-the-box on 2.6 kernels -- the 2.6 > > > > DRM must be downloaded from CVS installed separately (this does not seem > > > > to be documented) > > > > - My previously reported problem with glDrawPixels is still happens. > > > > Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The > > > > problem seems to be that glDrawPixels doesn't work to the back buffer. > > > > For example, the 'drawpix' demo shows blackness until the 'f' key is > > > > pressed to switch drawing to the front buffer. Drawpix works normally > > > > when LIBGL_ALWAYS_INDIRECT is set. > > > > > > > > It would appear that glDrawPixels is copying pixels to the wrong place. > > > > For example, see http://69.5.151.193/~sdh4/dribug.png. The black and > > > > colored stripes in this picture are texture portions corrupted by > > > > glDrawPixels. (There is supposed to be a map display in the lower right. > > > > The glDrawPixels() is supposed to copy this into the back buffer, > > > > instead it ends up splattered over the textures). In addition, if you > > > > look at the word 'East -76.' in the picture (under 'Marine park'), > > > > that text was written with glutBitmapCharacter() (translates to > > > > glBitmap()) to the (2D orthogonal) back buffer. > > > > > > I think I tracked this down. On supersavages (I don't know about > > > other savage4 based chips, I'll test it out tonight if I get a chance) > > > you need to shift the framebuffer offset passed to the tiled surface > > > registers by 6 rather than 5 (in savage_dri.c): > > > > > > } else { > > > if(pSAVAGEDRI->cpp == 2) > > > { > > > value |= (((pSAVAGEDRI->width + 0x3F) & 0xFFC0) >> 6) << 20; > > > value |= 2<<30; > > > } else { > > > value |= (((pSAVAGEDRI->width + 0x1F) & 0xFFE0) >> 5) << 20; > > > value |= 3<<30; > > > } > > > > > > OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI->frontOffset > > > >> 5) ); /* front */ > > > OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI->backOffset >> > > > 5) ); /* back */ > > > OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI->depthOffset > > > >> 5) ); /* depth */ > > > } > > > } > > > > > > Change the shift above from 5 to 6 and see if that fixes it for you. > > > the front buffer doesn't show any problems because the offset is 0. I > > > noticed this while debugging dualhead support on supersavage chips. > > > > To be clear, just change it for the OUTREG lines, not the lines above that. > > > > Alex > > > > > > > > Alex > > > > > > > > > > > Thanks, > > > > Steve > > > > > > > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
