The easiest way to get rid of tearing is to make the ring buffer wait before the back->front blit. This is a very simple mechanism that will work even for windowed 3d, and if you are running just one 3d client the wait time should not alter your performance much. Or rather, the performance decrease should not be different than any other "correct" rendering.
Just add a GFXCMDPARSER_LOAD_SCAN_LINES_INCL and a GFXCMDPARSER_WAIT_FOR_EVENT prior to the blit. This will hold the blit as long as it would tear on the screen. Small windows will not have to wait for a vblank, they only wait while the current scan intersects the blit. If you don't want to do that, you can just use the wait for event to block until the vblank as I mentioned before. This will make the rendering at least correct, you can then work on the page flipping as an optimization for full screen. -Matt -----Original Message----- From: Dave Airlie [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 6:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] [PATCH] i810 cleanup Well the i830 page flip code is using async flips, the main thing I want to use page flipping for on my i815 is sync'ed flips so I don't see the tearing that is so really obvious and gives people headaches.. (don't need to be getting sued here!!). It's not the timing I'm worried about it's the tearing, it can be slow as long as its not really ugly... the i815 can't do async page flipping properly anyways there is a bug in the silicon I would assume they fixed it for the i830 ... Also my current application is a single 3D window taking up the full screen, I doubt I'll ever any 2d windows interfering which is handy for me... My major issue now is finding a CVS tree which works for me on my development platform that I can then add code to. As my patch doesn't affect anything other than cleanup can you check it in? Dave. > The 830 page flipping code is turned off for some good reasons: > - I haven't seen it work without really visible corruption on the flip > - > typically flashing and blank areas > > - It isn't actually all that fast - there is a delay while (presumably) > the > ramdac cache or fifo drains - this is comparable to the time to blit the > window itself. The crossover point was about 300x300 on my test box, > but would vary for different machines. > > - Because of the above, it is necessary to wait for the flip to finish > before > clearing the backbuffer & starting the next frame, otherwise you see > this happen. Actually this invalidates my explanation of the delay -- > the fact that you can see the clear implies that the ramdac is still > grabbing new values from the frontbuffer, so I don't really know what > the delay arises from. > > Keith -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
