From: Felix <fx...@gm...> - 2002-10-14 20:36:57
Attachments:
radeon_smartwait.patch
r200_smartwait.patch
|
Hi, here is a new set of frame throttling patches for the radeon and r200 drivers. It implements a second chance strategy to avoid "ping-ponging" between busy waiting and IRQ waiting with very high frame rates. Best regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Dieter <Die...@ha...> - 2002-10-25 21:44:31
|
Am Montag, 14. Oktober 2002 22:36 schrieb Felix K=FChling: > Hi, > > here is a new set of frame throttling patches for the radeon and r200 > drivers. It implements a second chance strategy to avoid "ping-ponging" > between busy waiting and IRQ waiting with very high frame rates. Any results, yet? I give a whirl then. Thanks, Dieter |
From: Felix <fx...@gm...> - 2002-10-25 21:56:17
|
On Fri, 25 Oct 2002 23:44:21 +0200 Dieter Nützel <Die...@ha...> wrote: > Am Montag, 14. Oktober 2002 22:36 schrieb Felix Kühling: > > Hi, > > > > here is a new set of frame throttling patches for the radeon and r200 > > drivers. It implements a second chance strategy to avoid "ping-ponging" > > between busy waiting and IRQ waiting with very high frame rates. > > Any results, yet? I'm using the code for weeks now without problems. It's not yet commited, though. And I can't test it with R200. It shouldn't feel much different from the current version in CVS. > I give a whirl then. > > Thanks, > Dieter Keith, I'm also CC'ing to you. It's the other ping you asked for ;) Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2002-10-28 13:08:22
|
Felix K=FChling wrote: > Hi, >=20 > here is a new set of frame throttling patches for the radeon and r200 > drivers. It implements a second chance strategy to avoid "ping-ponging" > between busy waiting and IRQ waiting with very high frame rates. Felix, do you have versions of these that apply cleanly to the trunk? R= 200=20 in particular. Keiht |
From: Felix <fx...@gm...> - 2002-10-28 14:08:56
Attachments:
r200_smartwait.patch
radeon_smartwait.patch
|
On Mon, 28 Oct 2002 13:08:15 +0000 Keith Whitwell <ke...@tu...> wrote: > Felix Kühling wrote: [snip] > Felix, do you have versions of these that apply cleanly to the trunk? R200 > in particular. I suppose the applied cleanly two weeks ago ;) New versions are attached. > > Keiht > Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Felix <fx...@gm...> - 2002-10-29 02:22:02
|
On Mon, 28 Oct 2002 23:18:33 +0000 Keith Whitwell <ke...@tu...> wrote: > Felix Kühling wrote: > > On Mon, 28 Oct 2002 13:08:15 +0000 > > Keith Whitwell <ke...@tu...> wrote: > > > > > >>Felix Kühling wrote: > >> > > [snip] > > > >>Felix, do you have versions of these that apply cleanly to the trunk? R200 > >>in particular. > >> > > > > I suppose the applied cleanly two weeks ago ;) New versions are attached. > > Are you sure. Maybe I'm doing something wrong, but: Yes, I'm sure. With the r200 patch I attached to my last mail I get this output with your command sequence: felix@viking:~/dri/xc/xc/lib/GL/mesa/src/drv/r200$ rm r200_ioctl.c r200_context.[ch] felix@viking:~/dri/xc/xc/lib/GL/mesa/src/drv/r200$ cvs update r200_ioctl.c r200_context.c r200_context.h U r200_ioctl.c U r200_context.c U r200_context.h felix@viking:~/dri/xc/xc/lib/GL/mesa/src/drv/r200$ cvs status r200_ioctl.c r200_context.[ch] =================================================================== File: r200_ioctl.c Status: Up-to-date Working revision: 1.10 Repository revision: 1.10 /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) =================================================================== File: r200_context.c Status: Up-to-date Working revision: 1.13 Repository revision: 1.13 /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_context.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) =================================================================== File: r200_context.h Status: Up-to-date Working revision: 1.7 Repository revision: 1.7 /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_context.h,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) felix@viking:~/dri/xc/xc/lib/GL/mesa/src/drv/r200$ patch < r200_smartwait.patch patching file r200_context.c patching file r200_context.h patching file r200_ioctl.c cvs status shows the same versions as on your system. So the only explanation is that you're not using the most recent patch or something's wrong with your version of patch. When I wrote that my previous patches applied cleanly two weeks ago I was implying that things may have changed during that time and attached new patches against the current trunk. I hope this clears things up. Best regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2002-10-29 08:04:46
|
> cvs status shows the same versions as on your system. So the only > explanation is that you're not using the most recent patch or > something's wrong with your version of patch. > > When I wrote that my previous patches applied cleanly two weeks ago I > was implying that things may have changed during that time and attached > new patches against the current trunk. I hope this clears things up. Sorry Felix, My fault. I'm an idiot... Keith |
From: Keith W. <ke...@tu...> - 2002-10-29 13:23:29
|
Felix, I've cleaned up the WaitForFrameCompletion function a bit & committed. The logic is slightly different, but a lot easier to read/understand, I think. Keith |
From: Felix <fx...@gm...> - 2002-10-29 13:48:02
|
On Tue, 29 Oct 2002 13:23:22 +0000 Keith Whitwell <ke...@tu...> wrote: > Felix, > > I've cleaned up the WaitForFrameCompletion function a bit & committed. The > logic is slightly different, but a lot easier to read/understand, I think. Ok, I just think that the name rmesa->irqsEmitted is now a bit misleading (can't think of a better one, though). And you removed the delay loop. I remember reading a comment like "don't hammer the bus" in the old code. And by removing the delay loop you also eliminated the cause for the IRQ/busy ping ponging. So the irqsEmitted magic should be no longer necessary. Finally, if do_irqs is disabled you alsways use usleeps. But I assume it's your intention to never do real busy waiting. Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Keith W. <ke...@tu...> - 2002-10-29 14:10:01
|
Felix K=FChling wrote: > On Tue, 29 Oct 2002 13:23:22 +0000 > Keith Whitwell <ke...@tu...> wrote: >=20 >=20 >>Felix, >> >>I've cleaned up the WaitForFrameCompletion function a bit & committed. = The >>logic is slightly different, but a lot easier to read/understand, I thi= nk. >> >=20 > Ok, I just think that the name rmesa->irqsEmitted is now a bit > misleading (can't think of a better one, though).=20 Agreed, I can't either. > And you removed the > delay loop. I remember reading a comment like "don't hammer the bus" in > the old code. And by removing the delay loop you also eliminated the > cause for the IRQ/busy ping ponging. So the irqsEmitted magic should be > no longer necessary. The delay loop is eliminated by modern versions of gcc anyway. The=20 irqsEmitted magic is still necessary to avoid the (first) busywait, which= I'd=20 like to do. It basically says: "If I have to emit an irq for this frame= ,=20 then don't try to do without them for at least 9 more frames". This shou= ld=20 stop the pingponging in all but very marginal situations, and then it won= 't be=20 more than 1 pingpong per 10 frames. > Finally, if do_irqs is disabled you alsways use usleeps. But I assume > it's your intention to never do real busy waiting. No - there's an 'if (rmesa->do_usleeps)' protecting all relevent uses of=20 usleep, I think. Keith |
From: Felix <fx...@gm...> - 2002-10-29 14:17:41
|
On Tue, 29 Oct 2002 14:09:56 +0000 Keith Whitwell <ke...@tu...> wrote: > Felix Kühling wrote: > > On Tue, 29 Oct 2002 13:23:22 +0000 > > Keith Whitwell <ke...@tu...> wrote: > > > > > >>Felix, > >> > >>I've cleaned up the WaitForFrameCompletion function a bit & committed. The > >>logic is slightly different, but a lot easier to read/understand, I think. > >> > > > > Ok, I just think that the name rmesa->irqsEmitted is now a bit > > misleading (can't think of a better one, though). > > Agreed, I can't either. > > > And you removed the > > delay loop. I remember reading a comment like "don't hammer the bus" in > > the old code. And by removing the delay loop you also eliminated the > > cause for the IRQ/busy ping ponging. So the irqsEmitted magic should be > > no longer necessary. > > The delay loop is eliminated by modern versions of gcc anyway. The > irqsEmitted magic is still necessary to avoid the (first) busywait, which I'd > like to do. It basically says: "If I have to emit an irq for this frame, > then don't try to do without them for at least 9 more frames". This should > stop the pingponging in all but very marginal situations, and then it won't be > more than 1 pingpong per 10 frames. I see. > > > > Finally, if do_irqs is disabled you alsways use usleeps. But I assume > > it's your intention to never do real busy waiting. > > No - there's an 'if (rmesa->do_usleeps)' protecting all relevent uses of > usleep, I think. You're right, my fault. Then I guess we can officially close this thread ;-) > > Keith > Cheers, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Dieter <Die...@ha...> - 2002-10-29 22:29:47
|
Am Dienstag, 29. Oktober 2002 15:09 schrieb Keith Whitwell: > Felix K=FChling wrote: > > On Tue, 29 Oct 2002 13:23:22 +0000 > > > > Keith Whitwell <ke...@tu...> wrote: > >>Felix, > >> > >>I've cleaned up the WaitForFrameCompletion function a bit & committed.= =20 > >> The logic is slightly different, but a lot easier to read/understand, I > >> think. > > > > Ok, I just think that the name rmesa->irqsEmitted is now a bit > > misleading (can't think of a better one, though). > > Agreed, I can't either. > > > And you removed the > > > > delay loop. I remember reading a comment like "don't hammer the bus" in > > the old code. And by removing the delay loop you also eliminated the > > cause for the IRQ/busy ping ponging. So the irqsEmitted magic should be > > no longer necessary. > > The delay loop is eliminated by modern versions of gcc anyway. The > irqsEmitted magic is still necessary to avoid the (first) busywait, which > I'd like to do. It basically says: "If I have to emit an irq for this > frame, then don't try to do without them for at least 9 more frames". Th= is > should stop the pingponging in all but very marginal situations, and then > it won't be more than 1 pingpong per 10 frames. > > > Finally, if do_irqs is disabled you alsways use usleeps. But I assume > > it's your intention to never do real busy waiting. > > No - there's an 'if (rmesa->do_usleeps)' protecting all relevent uses of > usleep, I think. Have you great two guys latency (kernel preemption) in your mind, too? Latest test I did with 2.5.44+ (preemption enabled as always ;-) showed rea= lly=20 "bad" latency (~15 ms and more vs ~2ms with 2.4.17-aaX-2.4.19-preX-aaX) for= =20 the gfk subtest of latencytest0.42-pn. Regards, Dieter |