Re: Re: how to write snappy benchmark?

On Sun, 6 Jul 2003, Allen Akin wrote:

> On Sun, Jul 06, 2003 at 03:14:13PM -0700, Mark Vojkovich wrote:
> | > * Assuming the apps are capable of redrawing quickly enough to maintain
> | > interactivity, and the scheduler gives them time to do so. 
> | 
> |    I think if that were true we wouldn't be having this discussion.
> 
> Possibly.  It's important to know exactly why things are misbehaving
> now, and I haven't heard consensus on that yet.

   Not having a consensus doesn't make the correct conclusion any
less true.  People have already arrived at consensus to solve the 
wrong problems and that's why we are where we are at today.

   
> It's not due to lack of horsepower in the graphics subsystem, for
> several reasons including:  (1) Most 3D scenes in games are vastly more
> expensive to render than the typical GUI, yet are rendered with
> excellent responsiveness.  (2) Windows often seems faster when running
> on the same hardware.
> 
> There may be scheduler issues.  Alan said:
> 
> 	The 2.4-ac tree has the O(1) scheduler as has stuff like Red
> 	Hat.
> 
> My Ti4200 machine running RH 2.4.20-18.9 isn't noticeably snappier than
> before, so I don't know what's up there, yet.
> 
> And of course if some critical drawing operation isn't accelerated,
> there goes the ballgame.  RENDER does add some risk in that respect.
> 
> But I suspect it's mostly due to the toolkits and window managers being
> based on abstractions that optimize for goals other than performance.
> Those of you who have used Open Inventor and Performer, two high-level
> toolkits that yield significantly different performance for similar
> scenes running on the same hardware, know what I have in mind.  But
> without more hard data that's just a guess based on experience.
> 
> I brought up the subject of double-buffered displays without per-window
> backing store because the backing store just papers over the real
> problem, and costs a fair amount of memory in the bargain.  As you said,
> if the apps take a long time to render, you're still stuck looking at a
> stale image for a noticeable amount of time.

    I don't think apps take a long time to render.  They take a long
time to handle exposures.  Backing store doesn't paper over that
problem, it solves it.

> 
> |    Most OpenGL apps are the types of apps that don't need to handle
> | expose events.  And it's a good thing too, because they'd probably
> | suck at it.
> 
> In the IrisGL days, many apps were based on a simple model a lot like
> games:  Render continuously, and structure your pipeline so that there's
> no more than one frame of latency between an input and the first drawing
> command issued in response to it.  Exposure events were irrelevant.
> Rendering was always double-buffered and there was no expensive backing
> store per-window.  Those apps updated the screen cleanly, were extremely
> snappy, and were a joy to use.
> 
> Most current OpenGL apps wait for exposure events so that they're not
> burning CPU cycles unnecessarily.  But if they're otherwise structured
> in a similar way, and they're dispatched quickly enough, there's no
> fundamental difference between them and the old IrisGL apps.  If such an
> app can render a scene in a frame time, it feels fast.  There's nothing
> special about the API used for drawing, so I don't see why OpenGL apps
> would be any worse than Xlib-based apps or apps using any other
> reasonable accelerated API.

    You're right about there being nothing special about the API.

    I don't think most OpenGL apps wait for exposure events, and the
ones that do are very slow - worse than most 2D apps.  The fact that
nearly all DCC apps require overlay support are a testament to that.
They have big problems with this even when there aren't any other
apps that they have to share the screen with.


			Mark.