Bumping Unichrome Mesa dri driver version number?
Hi! Could somebody with CVS access to the Mesa tree bump the drm version number that the unichrome_dri driver expects from 1.1.x to 2.0.x? We had to bump the via drm major version a couple of weeks ago due to a fix on a bad IOCTL interface. Also I think the unichrome_dri driver needs to update it's definition of the private sarea. /Thomas --- 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
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
Re: Bumping Unichrome Mesa dri driver version number?
Thomas Hellström wrote: Hi! Could somebody with CVS access to the Mesa tree bump the drm version number that the unichrome_dri driver expects from 1.1.x to 2.0.x? We had to bump the via drm major version a couple of weeks ago due to a fix on a bad IOCTL interface. Also I think the unichrome_dri driver needs to update it's definition of the private sarea. Is CVS back online (properly)? The website is still down. I'll do this once Daniel's finished mucking with it. Keith --- 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: Bumping Unichrome Mesa dri driver version number?
Keith Whitwell wrote: Thomas Hellström wrote: Hi! Could somebody with CVS access to the Mesa tree bump the drm version number that the unichrome_dri driver expects from 1.1.x to 2.0.x? We had to bump the via drm major version a couple of weeks ago due to a fix on a bad IOCTL interface. Also I think the unichrome_dri driver needs to update it's definition of the private sarea. Is CVS back online (properly)? The website is still down. I'll do this once Daniel's finished mucking with it. Keith Thanks! /Thomas --- 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-deve l --- 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
Freedesktop.org (DRI and Mesa) aren't up, again?
/opt/Mesa date Do Nov 18 20:36:13 CET 2004 /opt/Mesa cvs update cvs [update aborted]: connect to pdx.freedesktop.org(131.252.208.82):2401 failed: Connection refused dri-trunk/xc cvs update cvs [update aborted]: connect to dri.freedesktop.org(131.252.208.82):2401 failed: Connection refused Thanks, Dieter --- 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: Freedesktop.org (DRI and Mesa) aren't up, again?
/opt/Mesa cvs update cvs [update aborted]: connect to pdx.freedesktop.org(131.252.208.82):2401 failed: Connection refused Read www.freedesktop.org...the machine was compromised and CVS has been shut down. -Steve --- 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
dri triple buffering?
I've got my internal app currently running with vblank_mode=2 at 60Hz, if I put in vblank_mode=3 I get a drop to about 40Hz which is no good for what I need I'm told that triple buffering might be the solution to this, does anyone know how much work this would be to implement in the radeon/r200 drivers? or dri in general? Initially I'd like to do it for a single full screen app (my case) and not worry about the issues with multiple apps... I would assume I need to allocate a 3rd buffer (wayback buffer...) in VRAM and have the bufferswap take an extra step to go wayback-back-front.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: compatibility problem with drm-core.
Hi! Jon Smirl wrote: I think this is happening for Thomas because he is running an older X server that isn't negotiating to the most current DRM interface. I believe the attached patch will fix the problem but we all need to test it to make sure it doesn't have unintended side effects. I don' t have an old X server around anymore to test for his exact problem. The patch you sent fixes the problem. /Thomas --- 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: dri triple buffering?
Dave Airlie wrote: I've got my internal app currently running with vblank_mode=2 at 60Hz, if I put in vblank_mode=3 I get a drop to about 40Hz which is no good for what I need I'm told that triple buffering might be the solution to this, does anyone know how much work this would be to implement in the radeon/r200 drivers? or dri in general? Initially I'd like to do it for a single full screen app (my case) and not worry about the issues with multiple apps... I would assume I need to allocate a 3rd buffer (wayback buffer...) in VRAM and have the bufferswap take an extra step to go wayback-back-front.. The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. A better sollution would be to forget pageflipping and have two back-buffers. The bufferswap routine would queue a blit from the current back-buffer to the front-buffer and switch back-buffers. You might want to coordinate some of this with Jacek. --- 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: compatibility problem with drm-core.
On Thu, 18 Nov 2004 22:13:23 +0100, Thomas Hellström [EMAIL PROTECTED] wrote: The patch you sent fixes the problem. I'm in the middle of moving to a new house so I will be off-line for at least a few more days. I don't have internet access at the new house yet, something is messed up in the CAT5 wiring. Maybe Dave can take care of this or you will need to wait for me to get moved in. -- Jon Smirl [EMAIL PROTECTED] --- 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: dri triple buffering?
The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. hehe, that's why I was mentioning only doing it for full screen apps :-), I'm using solo in my application at the moment anyways... I've also not used pageflipping as the Radeon M7 chip seems to have issues with it... The bufferswap routine would queue a blit from the current back-buffer to the front-buffer and switch back-buffers. You might want to coordinate some of this with Jacek. I think a fix in my app has made the tearing less often, I might get away with it, I also realised triplebuffer is freerunning CPU user I would like to use some of my CPU for other processes :-) so blocking on the swap is useful feature... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: dri triple buffering?
On Iau, 2004-11-18 at 23:22, Ian Romanick wrote: The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. No the X server needs to render everything (expensive bit) _once_. It needs to blit it to the other surfaces (cheap) once per surface. Thats a very important distinction. Especially as the shadowfb code just happens to include all the needed rectangle list stuff... Alan --- 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 Khling 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
