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. I've been playing around with page flipping and vblanks on mach64, and to get smooth rendering, here's what I had to do:
In the flip ioctl: 1. Wait for 3D idle. Unfortunately, on mach64 this means waiting for the ring to complete, as there is no "wait for idle/event" command that can be added to the ring. 2. Flip the CRTC offset register. 3. Wait for vblank before drawing again. I ended up allowing the flip ioctl to return without waiting, and using the vblank interrupt to determine when it's ok to flush/commit any commands added to the ring since the last flip ioctl. So instead of putting the process to sleep, I continue buffering commands on the ring and wait for an interrupt flag to be toggled by the service routine before commiting the ring. Without this, you see the card drawing before the vertical scan resets. BTW, with the current Radeon page flipping code without interrupts, how does it avoid flickering? It looks like there is a wait for 3D idle command added to the ring in step 1, but I don't see an equivalent to step 3. In practice, this method for mach64 works and there is less latency (e.g. with the quake 3 menu), but the framerate is lower than without page flipping and the 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. On 17 Sep 2002, Michel D�nzer wrote: > http://penguinppc.org/~daenzer/DRI/radeon-vblank.diff > > This patch against r200-0-2-branch adds an ioctl to wait for vertical > blank interrupts and has been working pretty well for me. I'd appreciate > some feedback about a couple points: > > * the interface allows waiting either for a specified number of vertical > blank interrupts (RADEON_VBL_RELATIVE) or for the interrupt with a > specific sequence number (RADEON_VBL_ABSOLUTE), in which case it also > returns if that sequence has occurred within about a day in the past. > The ioctl returns the current sequence number. > > Is this interface generic enough to make it a template, or should it > remain driver specific? > > * the 3D driver synchronizes the framerate to the vertical refresh if > the RADEON_THROTTLE_REFRESH environment variable is set; in contrast to > the naive hack I posted some time ago, it allows apps running at > framerates lower than the refresh to go as fast as they can instead of > only at fractions of the refresh. Is this a good name, or does anyone > have a better idea? > > > PS: Shouldn't it be wake_up_interruptible_all() instead of > wake_up_interruptible() in DRM(dma_immediate_bh)() as well? > > PPS: The branch doesn't build completely for me: > > radeon_dri.c: In function `RADEONDRIAgpHeapInit': > radeon_dri.c:848: `drmRadeonMemInitHeap' undeclared (first use in this > function) > radeon_dri.c:848: (Each undeclared identifier is reported only once > radeon_dri.c:848: for each function it appears in.) > radeon_dri.c:848: parse error before `drmHeap' > radeon_dri.c:853: `drmHeap' undeclared (first use in this function) > radeon_dri.c:853: `RADEON_MEM_REGION_AGP' undeclared (first use in this > function) > radeon_dri.c:857: `DRM_RADEON_INIT_HEAP' undeclared (first use in this > function) > make: *** [radeon_dri.o] Error 1 > make: Leaving directory > `/home/michdaen/src/dri-cvs/xc-r200/programs/Xserver/hw/xfree86/drivers/ati' > > That and the part of the patch above for > programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h make me > suspect that you've forgotten to commit some of your work, Keith? > > -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- 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
