Does OpenGL make any requirements on the atomic-ness (atomicity?) of a buffer flip? If so, I would assert that allowing part of a flip to be visible on one frame and the rest visible on the next is not a valid implementation and therefore the non-tearing implementation is a requirement not a feature.
On the other hand, if everyone is used to having no guarantee of non-tearing behavior then they would likely not welcome the change. Things like running gears at X FPS would certainly be slowed down. BTW: Did you go with "wait for scanline" or "wait for vblank"? The latter is more invasive... if you were doing multiple windowed clients there would only be ONE buffer flip per retrace to be shared between the clients. -Matt -----Original Message----- From: Dave Airlie [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 8:39 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Dri-devel] [PATCH] i810 cleanup Well that's a dodgy application on my part.. it now works sync'd with it .. How should I do this without changing the kernel i810 module? is there an way from the OpenGL level to do this that I could propogate down? Dave. Dave Airlie said: > > Nice one, that gets rid of my tearing - thanks Matthew, > > it works except now I get some jumpiness on my screen when a new texture > is coming on, I've got 5 rotating reels of 4 textured quads and when the > new ones are about to come on the top of the reel it seems to jump a > bit... > > Not sure if the fullscreen would help here.. I need to time each render > and see if this one takes a lot longer than the others.. > > Dave. > > Sottek, Matthew J said: >> >> 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 > > > -- > 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 -- 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: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
