Re: [Dri-devel] Fw: Improving Radeon interactivity

[Keith W. <ke...@tu...>]

Felix K=FChling wrote:
 > Hi Keith,
 >
 > since you're obviously back on the list I resend this message as Jens
 > Owen suggested in yesterday's IRC meeting. (I hope this is the last ti=
me
 > :) If someone has a log of the meeting, there was a more in depth
 > discussion of the topic.
 >
 > Begin forwarded message:
 >
 > Date: Sun, 8 Sep 2002 15:25:53 +0200
 > From: Felix K=FChling <fe...@vi...>
 > To: dri-devel <dri...@li...>
 > Subject: Improving Radeon interactivity
 >
 >
 > Hi list,
 >
 > on Friday I sent some thoughts and a patch to dri-devel concerning
 > interactivity of the Radeon. I didn't get any comments about it yet,
 > maybe I should have changed the subject. So I'm posting it again. Coul=
d
 > someone more knowledgeable than myself comment on it or even check it =
in
 > if appropriate?
 >
 > This was my problem (discussed with Michel D=E4nzer):
 >
 >>>>>1. With framerates below 50 or 60 there is a very noticable lag bet=
ween
 >>>>>input and graphics output. This is most obvious in the Quake3 main =
menu.
 >>>>>
 >>>>I think this is more of a Quake3 problem, IME interactivity can be g=
ood at
 >>>>much lower framerates.
 >>>>
 >>>Hmm, you're right, not all programmes are affected. Quake 1 and 2 wor=
k
 >>>fine. Quake 3, Torcs and Flightgear react with a delay.
 >>>
 >
 > And my understanding of the cause:
 >
 > I looked into the sources of plib and torcs and found out that plib
 > doesn't take care of swapping buffers or calling glFlush. It has to be
 > done by the application. Torcs uses glutSwapBuffers. I grepped the
 > quakeforge source and found that glFinish is called there before
 > glXSwapBuffers. That's why it reponds quickly.
 >
 > Some experiments:
 >
 > I was able to improve the response time of quake3, torcs and fgfs by
 > changing RADEON_MAX_OUTSTANDING in
 > lib/GL/mesa/src/drv/radeon/radeon_ioctl.c(line 610) from 2 to 0. It go=
t
 > even better when I moved the call to radeonWaitForFrameCompletion afte=
r
 > the DRM_RADEON_SWAP/DRM_RADEON_FLIP ioctl (lines 688-716,752-761). Now
 > it behaves effectively as if glFinish was called after glXSwapBuffers.

Does it really?  I think it's less severe than you think -- it only waits=
 for=20
the previous frame to complete, not everything in the pipe, doesn't it?

 > A good compromise may be to move radeonWaitForFrameCompletion as above
 > and set RADEON_MAX_OUTSTANDING to 1. This guarantees good response (ma=
x
 > 1 frame delay) and the hardware will hardly go idle. This is what the
 > attached patch does. Though I prefer RADEON_MAX_OUTSTANDING=3D0 for qu=
ake3
 > :).

I don't understand the difference between setting the MAX value to zero a=
nd
setting it to one, but moving it to after where the blit is emitted (and =
the
number is incremented).  They seem like identical approches...

The utah drivers did a pretty good job of ensuring concurrency while
preventing runaway situations.  They had two dma buffers, one being proce=
ssed
by the hardware, one being filled up by the driver.  If the driver got ah=
ead
of the hardware, it would have to wait for the 2nd dma buffer to become r=
eady.

Actually it seems to me this is equivalent to max_outstanding =3D=3D 0, l=
eaving=20
the test in its existing location...  Am I wrong?

Keith