[Dri-devel] Re: COMMIT_RING patches for r128
Henry Worth wrote: Digging thru the X logs, I see that agp is failing to map the ring buffer with this drm module. It does with kernel module built from BenH's linuxppc dev tree, but I haven't tried the dri CVS before, so I don't know yet if it even works without the COMMIT_RING changes. [...] Decided to do a quick compile and check before calling it a night. Without the patch, agp also fails to map the ring buffer. I'll take a look at merging in whatever fixes are in BenH's src tree tomorrow. Henry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: COMMIT_RING patches for r128
On Thu, 2002-07-18 at 09:47, Henry Worth wrote: Henry Worth wrote: Digging thru the X logs, I see that agp is failing to map the ring buffer with this drm module. It does with kernel module built from BenH's linuxppc dev tree, but I haven't tried the dri CVS before, so I don't know yet if it even works without the COMMIT_RING changes. [...] Decided to do a quick compile and check before calling it a night. Without the patch, agp also fails to map the ring buffer. I'll take a look at merging in whatever fixes are in BenH's src tree tomorrow. Like http://www.penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff ? :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Free Investor information 4108menj3-088-12
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D2_48A01D1A.A2548C67
Re: [Dri-devel] COMMIT_RING patches for r128
Henry Worth wrote: Michel, How do these changes for r128 COMMIT_RING look? With these I can run concurrent xine and glx programs in pci and agp mode with XV dma disabled. With XV dma enabled, in both pci and agp mode, I can run xine for some time without any hangs. But startup a glx program and X will hang until I kill the glx program, and then X and xine will recover. I guess sync is the next issue, I have a follow-on question on that below. The patch also includes a change to RING_SPACE_TEST..., based on the radeon version, adding a register read fallback for determining ring space. I have no idea why there is a need for the RING_SPACE_TEST macro. It's disabled in the r200 branch. The current drm r128 does not have any WAIT_UNTIL_*_IDLE macros. I assume I'm going to need at least a general idle wait to address sync issues. The only WAIT_UNTIL mask bit defined in r128_drv.h is for page flip, are there any other bits available for wait functions? What does the r128 currently do to synchronize access to the framebuffer? It may be that 2d 3d are synchronized by the hardware automatically, but you'll always need to do something before accessing the framebuffer directly. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] COMMIT_RING patches for r128
On Thu, 2002-07-18 at 16:40, Keith Whitwell wrote:
Henry Worth wrote:
Michel,
How do these changes for r128 COMMIT_RING look? With these I can run
concurrent xine and glx programs in pci and agp mode with XV dma
disabled.
With XV dma enabled, in both pci and agp mode, I can run xine for some
time without any hangs. But startup a glx program and X will hang until I
kill the glx program, and then X and xine will recover. I guess sync is the
next issue, I have a follow-on question on that below.
The patch also includes a change to RING_SPACE_TEST..., based on
the radeon version, adding a register read fallback for determining ring
space.
I have no idea why there is a need for the RING_SPACE_TEST macro. It's
disabled in the r200 branch.
Besides, I've never hit the added code there.
The current drm r128 does not have any WAIT_UNTIL_*_IDLE macros.
I assume I'm going to need at least a general idle wait to address sync
issues. The only WAIT_UNTIL mask bit defined in r128_drv.h is for page
flip, are there any other bits available for wait functions?
What does the r128 currently do to synchronize access to the framebuffer?
XAA handles that, and both drivers provide WaitForIdle() as the Sync
function.
It may be that 2d 3d are synchronized by the hardware automatically,
I doubt that, e.g. the texture blit ioctl also flushes the pixel cache.
Maybe there's more to do with the PC_{,N}GUI_* registers?
but you'll always need to do something before accessing the framebuffer
directly.
I don't see where direct framebuffer access is involved when using DMA
transfers for Xv.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
AGP has become very stable here since the radeon driver doesn't update the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING(). Seems updating it 'too often' is no good, for whatever 'too often' may mean. I hate that. It should be fully stable or I would consider it unuseable :( On my side, I've temporarily given up trying to understand what was going on. Does anybody have useful contacts at ATI that could help ? I have 2 possible ideas: - Some athlon-like cache aliasing issues, though I don't think PPCs do that aggressive prefetch accross page boundaries - Some magic skew value to set in the chip to compensate for some bus arbitration issues when mixing AGP master transfers and PCI slave transfers. Or maybe just disabling some of the AGP features like Fast Write... Ben. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segmentation fault with Radeon 7500 QW
On Mon, 2002-07-15 at 23:13, Steven Walter wrote: I recently bought a Radeon 7500 64MB DDR (lovingly called a QW), and have had no luck with the DRI cvs trunk. 3D acceleration /does/ work, however, with xfree86 4.2 The problem is, whenever I run a 3d app, I get a segmentation fault. Running strace on said apps reveals that the segfault right after: old_mmap(NULL, 499712, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x44dcf000 I also see weird problems like this, but only under special circumstances, e.g. when xscreensaver launches a hack, so I haven't been able to investigate. Can you run a client in gdb and provide a backtrace? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 11:18:59PM +0200, Charl P. Botha wrote: I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in throwing away all my data) kernel a shot to see whether updates to agpgart make any difference. This experiment wasn't successful either. I tried with numerous different configs (radeon and agpgart modules, agpgart in kernel radeon module, both in kernel) but could still reproduce the switch to VT and back freeze every time. Thinking that the LockHeld semaphore which was added to i810_driver.c (as well as i830) to prevent syncs when DriLock hadn't been called was relevant (it was reported that this had caused hangs on VT switches on those chipsets) I implemented this locking in radeon_driver.c and radeon_dri.c as well. Still no luck... Does anyone have any other ideas? Best regards, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: COMMIT_RING patches for r128
Michel Dänzer wrote: On Thu, 2002-07-18 at 09:47, Henry Worth wrote: Henry Worth wrote: Digging thru the X logs, I see that agp is failing to map the ring buffer with this drm module. It does with kernel module built from BenH's linuxppc dev tree, but I haven't tried the dri CVS before, so I don't know yet if it even works without the COMMIT_RING changes. [...] Decided to do a quick compile and check before calling it a night. Without the patch, agp also fails to map the ring buffer. I'll take a look at merging in whatever fixes are in BenH's src tree tomorrow. Like http://www.penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff ? :) Exactly like that... AGP is mapping the ring now. So to the results -- again this is with dual 450 G4's with SMP linux 2.4.19-rc1-ben0, DRI CVS from Monday on top of XFre86 2.4.0 with the Michel's XV dma patch, indirect buffering patch, ioremap patch, the r128 endiness patches and the COMMIT_RING changes. While it is still possible to hang X in any combination of PCI/AGP mode and XV dma enabled/disabled by mixing various pairs of XV, DRI, and concurrent X activity, like x11perf, in general it takes more effort. When it does hang I've yet to see a hard hang of the X server or of the system, as was common before. In all hang cases the offending processes could be killed and X would continue, if I was lucky enough to kill the right process, other processes would restart. Previously enabling XV dma, xine starting play would almost always hang in a very short time with SMP kernels. On occasions it did play for a while, trying to move another window was extremely jerky and slow, dispite a very low CPU load (10-15%), and would always result in an eventual hang. Hangs almost always required a reboot to recover. Now, xine with XV dma will play as long as there isn't much other X activity. X remains responsive with windows moving fairly smoothly. I was even able to run X11perf for a couple of minutes before problems occured. But, I've yet to see a literal hang, except when starting a GLX program, and killing the GLX program allowed xine to continue. The problem I now see repeatedly with XV dma is that eventually X11perf or moving a window will cause video sync to go haywire. Xine is playing audio and the keyboard is responsive, and I can ctl-alt-del. But video sync does not recover when X exits or is restarted, a reboot is required to reset the video card. Previously I had somethimes seen a problem like this, but never had keyb responsiveness and attempts to recover from a telnet session often resulted in a system hang when trying to kill X or perform a shutdown. Overall, pci mode and XV dma disabled is still the most stable mode, but agp mode with XV dma disabled is more usable. I was able to run the Mesa terrain demo with texture, two gears demos and x11perf in agp mode for 20minutes, with frequent moving and raising of windows, before a deadlock that was cleared by killing the glx processes. BTW, I do see quite a few 128(0): Idle timed out, resetting engine... being logged by r128_accel.c's R128WaitForIdle() routine when running x11perf with both the old and new drivers. Henry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] COMMIT_RING patches for r128
Michel Dänzer wrote:
On Thu, 2002-07-18 at 16:40, Keith Whitwell wrote:
Henry Worth wrote:
I have no idea why there is a need for the RING_SPACE_TEST macro. It's
disabled in the r200 branch.
Besides, I've never hit the added code there.
Ok, I won't worry about that.
The current drm r128 does not have any WAIT_UNTIL_*_IDLE macros.
I assume I'm going to need at least a general idle wait to address sync
issues. The only WAIT_UNTIL mask bit defined in r128_drv.h is for page
flip, are there any other bits available for wait functions?
What does the r128 currently do to synchronize access to the framebuffer?
XAA handles that, and both drivers provide WaitForIdle() as the Sync
function.
It may be that 2d 3d are synchronized by the hardware automatically,
I doubt that, e.g. the texture blit ioctl also flushes the pixel cache.
Maybe there's more to do with the PC_{,N}GUI_* registers?
but you'll always need to do something before accessing the framebuffer
directly.
I don't see where direct framebuffer access is involved when using DMA
transfers for Xv.
So where to go from here? I can only spend a couple more days on this in
the near
term, so I don't have time to deal with the NDA and digging thru the
docs. Unless
someone else has a good recommendation, I'll try to flesh out some sync code
based on the radeon code and maybe someone else can correct the details
later.
Henry
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
Dear list, On Thu, Jul 18, 2002 at 07:04:25PM +0200, Charl P. Botha wrote: Thinking that the LockHeld semaphore which was added to i810_driver.c (as well as i830) to prevent syncs when DriLock hadn't been called was relevant (it was reported that this had caused hangs on VT switches on those chipsets) I implemented this locking in radeon_driver.c and radeon_dri.c as well. Still no luck... I built XFree86 from the DRI tree with -g as well as #define GlxBuiltInRadeon YES in the host.def in order to try and get an almost usable backtrace. After having crashed X by switching to VT and back (at least this is 100% reproducible) I attached to the process with gdb (ssh'd from another machine). I've attached the backtrace... it has a tad more detail than normal, but is there a way to get something a little more verbose? Maybe this shakes some marbles in some of the developers' heads (in a most pleasant manner, of course). Any more ideas would be greatly appreciated, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ (gdb) bt #0 0x40118054 in ioctl () from /lib/libc.so.6 #1 0xfc02 in ?? () #2 0x083b6f60 in ?? () #3 0x08533a6f in ?? () #4 0x0858eec0 in ?? () #5 0x08163c0b in miSpriteGetImage (pDrawable=0x881b7b8, sx=2, sy=7, w=16, h=16, format=2, planemask=4294967295, pdstLine=0xb454 À'\t) at misprite.c:494 #6 0x085c7c22 in ?? () #7 0x080b201f in DoGetImage (client=0x8755d88, format=2, drawable=6291997, x=2, y=7, width=16, height=16, planemask=4294967295, im_return=0x0) at dispatch.c:2256 #8 0x080b21db in ProcGetImage (client=0x8755d88) at dispatch.c:2350 #9 0x080aea86 in Dispatch () at dispatch.c:462 #10 0x080beb3b in main (argc=5, argv=0xbbb4, envp=0xbbcc) at main.c:454
Re: [Dri-devel] Radeon problems with rendering into front buffer.
Michel Dänzer wrote: On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote: BTW: Why in function radeon_emit_clip_rect (xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c) line: /* OUT_RING( ((box-y2 - 1) 16) | (box-x2 - 1) );*/ is conmmented? I think it's correct, following line: OUT_RING( (box-y2 16) | box-x2 ); results in OpenGL rendering primitives into other windows (cliprect one pixel too wide and high) clearing is OK in both cases. I have only been able to reproduce the problem in BillardGL, do you have other test cases and an explanation why other apps don't show the problem? Sorry for not answering immidiately but I was abroad. I think it's general problem of all OpenGL apps when pageflip is enabled. For example here is atlantis (xscreensaver). http://stud.ics.p.lodz.pl/~paproch/dri/border.jpg And another strange thing after shading window: http://stud.ics.p.lodz.pl/~paproch/dri/shaded.jpg those sharks are moving. The same with glxgears and other apps. Now I use debian woody with trunk code compiled but the same problem occured with slackware. Jacek -- Darmowe konta e-mail 30 MB, w idealnej domenie, czyli [EMAIL PROTECTED] i wszystko jasne! Zapraszamy! http://www.twoje.konto.pl --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon problems with rendering into front buffer.
Jacek Rosik wrote: Michel Dänzer wrote: On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote: BTW: Why in function radeon_emit_clip_rect (xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c) line: /* OUT_RING( ((box-y2 - 1) 16) | (box-x2 - 1) );*/ is conmmented? I think it's correct, following line: OUT_RING( (box-y2 16) | box-x2 ); results in OpenGL rendering primitives into other windows (cliprect one pixel too wide and high) clearing is OK in both cases. I have only been able to reproduce the problem in BillardGL, do you have other test cases and an explanation why other apps don't show the problem? Sorry for not answering immidiately but I was abroad. I think it's general problem of all OpenGL apps when pageflip is enabled. For example here is atlantis (xscreensaver). http://stud.ics.p.lodz.pl/~paproch/dri/border.jpg And another strange thing after shading window: http://stud.ics.p.lodz.pl/~paproch/dri/shaded.jpg those sharks are moving. The same with glxgears and other apps. It looks like the 'zero cliprects' case doesn't work -- it keeps on using the last-set cliprect -- ie whatever's in hardware. Previously you didn't see these droppings because they were never blitted to the front buffer. It shouldn't be too hard to fix. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Thu, 2002-07-18 at 21:29, Charl P. Botha wrote: On Thu, Jul 18, 2002 at 07:04:25PM +0200, Charl P. Botha wrote: Thinking that the LockHeld semaphore which was added to i810_driver.c (as well as i830) to prevent syncs when DriLock hadn't been called was relevant (it was reported that this had caused hangs on VT switches on those chipsets) I implemented this locking in radeon_driver.c and radeon_dri.c as well. Still no luck... I built XFree86 from the DRI tree with -g as well as #define GlxBuiltInRadeon YES in the host.def in order to try and get an almost usable backtrace. After having crashed X by switching to VT and back (at least this is 100% reproducible) I attached to the process with gdb (ssh'd from another machine). I've attached the backtrace... it has a tad more detail than normal, but is there a way to get something a little more verbose? Either call LoaderPrintSymbol() for each of the addresses with a '??' or run a static server (#define DoLoadableServer NO in host.def). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
On Thu, 2002-07-18 at 18:20, Benjamin Herrenschmidt wrote: AGP has become very stable here since the radeon driver doesn't update the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING(). Seems updating it 'too often' is no good, for whatever 'too often' may mean. I hate that. It should be fully stable or I would consider it unuseable :( Define 'fully stable' - no crash to infinity and beyond? ;) I can run for days without crashes on this TiBook, I consider that quite good. On my side, I've temporarily given up trying to understand what was going on. Does anybody have useful contacts at ATI that could help ? I have 2 possible ideas: - Some athlon-like cache aliasing issues, though I don't think PPCs do that aggressive prefetch accross page boundaries And in that case, I'd expect the problem to be (mostly) independent from driver changes. - Some magic skew value to set in the chip to compensate for some bus arbitration issues when mixing AGP master transfers and PCI slave transfers. Or maybe just disabling some of the AGP features like Fast Write... Something like that seems much more likely to me, seeing as throttling the ring write pointer updates helps a great deal. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon problems with rendering into front buffer.
On Thu, 2002-07-18 at 23:08, Jacek Rosik wrote: Michel Dänzer wrote: On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote: BTW: Why in function radeon_emit_clip_rect (xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c) line: /* OUT_RING( ((box-y2 - 1) 16) | (box-x2 - 1) );*/ is conmmented? I think it's correct, following line: OUT_RING( (box-y2 16) | box-x2 ); results in OpenGL rendering primitives into other windows (cliprect one pixel too wide and high) clearing is OK in both cases. I have only been able to reproduce the problem in BillardGL, do you have other test cases and an explanation why other apps don't show the problem? Sorry for not answering immidiately but I was abroad. I think it's general problem of all OpenGL apps when pageflip is enabled. For example here is atlantis (xscreensaver). http://stud.ics.p.lodz.pl/~paproch/dri/border.jpg I see, I was looking in the wrong places. I just committed your fix, thanks. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: COMMIT_RING patches for r128
I've been doing some more testing. With, and without, the commit_ring patches, even in pci mode, I can get X to hang without too much effort by firing up several glx demos and then x11perf. One of the glx programs will hang holding hw locks in r128WaitForFrameCompletion() from r128CopyBuffer(). The other glx programs are in the drmGetLock() ioctl from one of the r128render* functions, and x11perf in select from _XWaitForWritable(). Once the glx programs and x11perf are killed, the X server hang clears, but any attempt to start a glx program will hang the X server in the same r128WaitForFrameCompletion() from r128CopyBuffer() condition on it's first frame. A restart of X is required to reset drm. Henry --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Website update - URL
Howzit? Thanks to all those who have been helping me, this has got done a lot quicker than it otherwise would have, and the DRI site is still standing ;-). Anyhow: http://dri.sourceforge.net/site_update/ All comments, suggestions, requests are welcome. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
