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. Also make sure that interrupts are working. Does the radeon DRM show up in /proc/interrupts? > > TIA, > > Kevin O'Brien HTH, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- 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
