On Die, 2002-09-17 at 21:29, Leif Delgass wrote: > On 17 Sep 2002, Michel D�nzer wrote: > > > On Die, 2002-09-17 at 20:14, Leif Delgass wrote: > > > Don't you want to wait for the vblank _after_ the flip ioctl? That way > > > you won't draw on the buffer being currently scanned until the vblank > > > indicates the buffers toggled. > > > > That may be true if the flip only occurs on vertical blank, which isn't > > the case in the radeon driver to allow insanely high framerates. > > Does that mean the Radeon starts scanning from the new offset immediately?
Yes, we currently set it up like that. It can also wait for the current scanline or frame to complete. > > > BTW, with the current Radeon page flipping code without interrupts, how > > > does it avoid flickering? > > > > Not at all, the flip occurs immediately. > > But even if the card can process the flip before vblank, doesn't that > still cause tearing/shearing? Of course, but FPS junkies don't care. :) > > > [...] framerate is capped to the vertical refresh (e.g. > > > glxgears maxes out at the vertical refresh). It seems like the main > > > problem affecting the frame rate is the wait for idle in step 1. > > > > You can't have framerates higher than the vertical refresh when syncing > > to vertical blanks, or how would you expect that to work? > > I don't expect to be able to get higher than vertical refresh, I was just > pointing that out as a side-effect of the way I'm doing page flipping. > Without interrupts, it slows things down even more to block until vblank > in the ioctl. When I talk about step 1 (wait for 3D idle) reducing the > framerate I mean, for example in Quake3 where the framerate is ~21 without > page flipping, I _loose a few FPS with pageflipping. I think this is > because I have to wait for idle every frame, instead of being able to have > two or three frames on the ring at a time. I don't see a way around that > though, since there's no way to add the wait+flip to the ring. The radeon driver is better off there because it can trigger the flip via the CP stream. -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
