On Thu, 2004-11-18 at 03:57, Felix KÃhling wrote: > Am Do, den 18.11.2004 schrieb Kevin O'Brien um 8:03: > > I need to get a animated line drawing graphics package working on a > > Radeon 9000 without artifacts. Currently, I get remnants of the > > previous frame after glXSwapBuffers on large windows, 1024x768 for > > example. This results in a tearing effect on the screen. > > > > Pseudo code: > > glFinish(); > > glXSwapBuffers(dpy, win); > > glFinish(); > > PrintCurrentVerticalLine(); // reads current vline from Radeon chip > > > > The value reported by the code is approx. the scan line where the > > tearing occurs. > > > > This can also be demonstrated with glxgears by resizing the window to > > 1024x768 and moving the window up high enough so the title bar is mostly > > hidden. /etc/drirc has vblank_mode set to 3 for all apps, including > > glxgears. > > > > As a test application, I create a window and draw a vertical line where > > the x component increases by one each frame. If the window is small > > enough, there is no problem; large enough, it tears The portion of the > > previous frame is related to the size of the window. > > > > I've also tried setting vblank_mode to 0 and invoking: > > > > drm_wait_vblank_t ioctl_arg; > > glFinish(); > > ioctl_arg.request.type = _DRM_VBLANK_RELATIVE; > > ioctl_arg.request.sequence = 1; > > ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &ioctl_arg); > > glXSwapBuffers(dpy, win); > > glFinish(); > > PrintCurrentVerticalLine(); > > > > and the results are the same as before. > > > > My environment: > > Multiple computers > > Xorg 6.8.0-r1 (Gentoo) or XFree 4.3.99 (SuSE 9.1) > > Radeon Mobility 9000 M9 or Radeon Mobility 7500 M7 > > Desktop: 1024x768 16bit or 24bit > > Xorg/XFree w/ DRI/DRM or Xorg w/ ATI's proprietary driver. > > > > I don't see this effect when using an nVidia Corporation NV18 [GeForce4 > > MX] w/ nVidia's drivers. Unfortunately, I have to get a Radeon solution > > working. > > > > Any thoughts where to look for a solution, or why it is related to > > window size, would be greatly appreciated. > > There is a problem in the radeon driver WRT to waiting for the refresh. > The driver can wait for the refresh but there is no guarantee that the > next operation can take place immediately, because there may still be > more commands pending in the command queue. Calling glFinish before > glXSwapBuffers should normally fix this. If there is still visible > tearing the only reason I could imagine is that the blit from back > buffer to front buffer takes longer than the vertical retrace. In that > case page flipping might solve your problem. Set 'Option > "EnablePageFlip" "true"' in the Device section of xorg.conf or > XF86Config[-4] respectively. >
Page flipping doesn't work with Merge Frame Buffer, another requirement. > Also make sure that interrupts are working. Does the radeon DRM show up > in /proc/interrupts? > Yes. > > > > TIA, > > > > Kevin O'Brien > > HTH, > Felix Thanks for the response. Is there a way to ensure the Radeon blits from top to bottom? radeon_accelfuncs.c has code that suggests it is programming the chip for top down blits. And modifying the code to reverse the blit direction has no effect on my problem. Since blitting is faster than refresh rate, blitting from the top to bottom should produce a "tear" free display - if the blit begins before start of active display. If the Radeon is blitting from bottom to top, a "tear" would occur if the blit is longer than vertical blank when the active picture meets the blit. Reading the current vertical line for start of blit (return from glXSwapBuffers) to end of blit (the glFinish following the glXSwapBuffers) produces values suggesting a limit around 384K pixels for bottom to top blits. And windows sized this way reveal they're at the boundary between tearing and tear free rendering. Thanks again, Kevin ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
