Re: Bad display on Radeon when DRI syncd w vblank
On Fri, 2004-11-19 at 11:17, Michel DÃnzer wrote: > On Fri, 2004-11-19 at 00:44 -0600, Kevin O'Brien wrote: > > 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: > > > > Page flipping doesn't work with Merge Frame Buffer, [...] > > Sounds like a bug that should be fixed. > > What I see is the contents of the primary display duplicated on the second. If there are any hints where to look, I'd be very happy to try to investigate this. > > Is there a way to ensure the Radeon blits from top to bottom? > > Sure, by setting the DST_Y_TOP_TO_BOTTOM bit in the DP_CNTL register. > Might be a good idea to do that in radeon_cp_dispatch_swap(). > Alas, I can't get this to work. My changes have no effect on the problem. I increased the size of BEGIN_RING to hold the two entries required to do this. First attempt tried using OUT_RING_REG. Second attempt was to use two OUT_RING calls. I also tried adjusting DP_CNTL_XDIR_YDIR_YMAJOR (based on definitions in DRI.) > > 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. > > You're assuming there's no (scheduling, ...) lag between the vertical > blank and the emission of the buffer swap... > While obviously not a generic solution, I may have a work-around by using multiple blits: First blit is the top third. Second blit is the bottom two thirds. (Dividing it into two equal halves ALMOST worked - a little noisy on the top line.) I now have two 1024x768 windows, one on each head, with no visible artifacts - with limited testing. NOTE: this also required a tweak to the X driver to ensure the vertical sync of the two monitors coincide. --- 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
Re: Bad display on Radeon when DRI syncd w vblank
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
Bad display on Radeon when DRI syncd w vblank
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. TIA, Kevin O'Brien --- 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
