Re: Re: how to write snappy benchmark?

On Mon, 7 Jul 2003, Allen Akin wrote:

> On Mon, Jul 07, 2003 at 11:14:34AM -0700, Mark Vojkovich wrote:
> | > 
> | > |    I believe that direct rendering will make the latency worse in
> | > | the case of exposures.  It does for 3D.  Nothing has changed from
> | > | the description I gave above except that now the apps all have
> | > | to synchronize with the X-server before they can render.  ...
> | > 
> | > That wasn't true for systems I've worked on in the past, so I don't
> | > believe it's true in general.  If it's a bottleneck in our current
> | > systems, at least it's something those of us working at the low level
> | > can fix to make life easier for those higher in the food chain.
> | > 
> |    Perhaps you can give a specific platform and an example of 
> | how moving a window while 3D is running doesn't insert pipeline
> | bubbles.
> 
> First you said that the apps have to synchronize with the X server.  Now
> you say that a pipeline bubble has to be introduced.  Those aren't at
> all the same thing, so be careful about which claim you're really trying
> to make.
> 
> On systems where the command stream to the drawing engine uses
> window-relative coordinates and doesn't include any information derived
> from the clipping region, the X server pauses the command stream from
> the app, adjusts window-origin and clipping information, then restarts
> the command stream.  This usually does introduce bubbles (in-flight
> drawing operations have to drain from the pipe), but there's no
> handshake between the app and the server.  In particular there's no
> round-trip communication between the two.  
> 
> So I'll stick by my original assertion that synchronization isn't
> required, and if the synchronization that's happening with today's
> systems is causing a problem, then it's something those of us working on
> low-level graphics should try to improve.  Don't try to read any more
> into it than that.

   Pipelines are deep.  Waiting for the engine to go idle between
context switches is more expensive than it used to be in the old PIO 
world because the "pipeline" essentially includes stuff in the DMA 
buffer that hasn't been read by the hardware yet.  Also, these
hardware clients have to reassert the state of the hardware when
they get it (who knows what state the last client left it in).

   At least in the case of the DRI, this involves taking system-
wide mutexes and stuff.  NVIDIA hardware and direct rendering architecture 
have an advantage here compared to normal PC hardware with the DRI, but 
it's still a problem.


			Mark.