From: "Stephen C. Tweedie" <sct@redhat.com>
To: James Simmons <jsimmons@edgeglobal.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Marcus Sundberg <erammsu@kieraypc01.p.y.ki.era.ericsson.se>,
linux-mm@kvack.org
Subject: Re: accel handling
Date: Mon, 30 Aug 1999 16:52:49 +0100 (BST) [thread overview]
Message-ID: <14282.43218.149092.491404@dukat.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.9908301043070.3506-100000@imperial.edgeglobal.com>
Hi,
On Mon, 30 Aug 1999 10:50:11 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:
> The way the accel engine will work is that it will batch accel commands.
> Then when full flush them to the accel engine. So we can batch a hugh
> number of commands to avoid the expensive process of flipping page tables.
> Of course the buffer is of variable size. The size determined by how many
> accel commands you want to send to the engine to display a frame. So a
> complex scene would be worth it.
For graphics, latency is important. You can't afford to arbitrarily
batch things up into things only getting sent every hundred msec or so.
Also, depending on what you are doing, you can be streaming things to
the accel engine _fast_: for 3D, for example, the DRI people talk about
sending a new command queue to an accelerator at the rate of a few
thousand per second. For 2D animation you are probably talking about
at least hundreds per second, depending on how much is going on. Much
less than that and the latency becomes visible.
> The secert is to do a as few times possible.
If that results in a performance drop, then it kind of defeats the idea
of having an accel engine.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-08-30 15:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-29 14:52 James Simmons
1999-08-29 16:14 ` Stephen C. Tweedie
1999-08-30 1:14 ` James Simmons
1999-08-30 10:44 ` Stephen C. Tweedie
1999-08-30 12:06 ` Marcus Sundberg
1999-08-30 14:18 ` Stephen C. Tweedie
1999-08-30 14:50 ` James Simmons
1999-08-30 15:52 ` Stephen C. Tweedie [this message]
1999-08-30 17:51 ` James Simmons
1999-08-30 20:27 ` Stephen C. Tweedie
1999-08-31 0:28 ` Vladimir Dergachev
1999-08-31 10:55 ` Marcus Sundberg
1999-08-31 12:49 ` Stephen C. Tweedie
1999-08-31 17:10 ` James Simmons
1999-08-31 18:44 ` Stephen C. Tweedie
1999-08-30 14:31 ` James Simmons
1999-08-30 18:51 ` Eric W. Biederman
1999-08-30 19:18 ` James Simmons
1999-08-30 21:39 ` Andreas Beck
1999-08-30 20:36 ` Stephen C. Tweedie
1999-08-29 14:57 James Simmons
1999-08-31 3:39 Jens Owen
1999-08-31 12:51 ` Stephen C. Tweedie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14282.43218.149092.491404@dukat.scot.redhat.com \
--to=sct@redhat.com \
--cc=erammsu@kieraypc01.p.y.ki.era.ericsson.se \
--cc=jsimmons@edgeglobal.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox