Re: Quake performance SGI vs Sun
From: joe smith (rapu_at_ra73727uashduashfh.org)
Date: 04/05/04
- Previous message: Oscar del Rio: "Re: Video Frame Grabber for SunBlade"
- In reply to: Robin KAY: "Re: Quake performance SGI vs Sun"
- Next in thread: Alexis Cousein: "Re: Quake performance SGI vs Sun"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 5 Apr 2004 20:14:15 +0300
> The latency is the time between rendering the frame and displaying it.
> With double buffering, once a frame has been rendered it can be
> displayed immediately. With multibuffering, the pending frame(s) must be
> displayed before the frame you just rendered so the latency is
> increased. Multibuffering does increase the rate at which frames can be
> displayed but at the expense of greater latency (i.e. slower response
> times).
That's what I am trying to explain here. Definitely, if you update
simulation at the time the previous frame is pending display, and we start a
new frame, it will be displayed 1.0 + n frames from now, where n is a value
between eps and 1.0-eps, which is the time until the previously rendering
frame is fully diplayed and the graphics context is freed.
No magic there. You claim that the latency is 'smaller', when we wait extra
time between eps and 1.0-eps frames before we update our simulation. This
time is latency itself, is it not? If user gives input between this time
period, when will the results be visualized? If more 'recent' user input is
visualized, then it can be said there is 'no latency', but this is illusion
and misleading at best, with triple buffering, in worst case, we get
precisely the same latency as with double buffering when we know what we are
doing - this is a VERY important part. ;-)
How you think simulations sample the input devices? Do they take snapshot at
specific time, or do they sample continuously over time and average? How you
do 'simulate' continuousness of reality with fixed timesteps? For games it
is adequate to sample once, not continuously and compute the average, is it
not a game we are talking about here? If it is critical for you when the
sampling is done from the input device(s) it gives out one thing about the
approach you propose: fixed time, single-sample input. For instance, if we
have a stick on airplane, you sample the two axis of the stick at specific
time and that's it. This is only extrapolation from your stance on the
latency issue, feel free to correct any possible misconception.
With triple buffering the graphics context is freed earlier. On a fillrate
limited systems such as SGI's it would be very advantageous if you could
clear the framebuffer *1) as early as possible, to delay the rendering of
the simulation / feedback based portions of the frame to as late as
possible, so that the "delay" would be minimized. If the SGI's are fillrate
limited, there seems to be no disagreement about this (?) triple buffering
would be a great help, even when doing simulation work, would it not? For me
this is plain obvious, isn't it for you?
*1) Clearing the color and depth buffers can be avoided if specific
conditions are met.
- Previous message: Oscar del Rio: "Re: Video Frame Grabber for SunBlade"
- In reply to: Robin KAY: "Re: Quake performance SGI vs Sun"
- Next in thread: Alexis Cousein: "Re: Quake performance SGI vs Sun"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
