From: "Stephen C. Tweedie" <sct@redhat.com>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: James Simmons <jsimmons@edgeglobal.com>,
Marcus Sundberg <erammsu@kieraypc01.p.y.ki.era.ericsson.se>,
"Stephen C. Tweedie" <sct@redhat.com>,
linux-mm@kvack.org
Subject: Re: accel handling
Date: Mon, 30 Aug 1999 21:36:09 +0100 (BST) [thread overview]
Message-ID: <14282.60217.253262.910401@dukat.scot.redhat.com> (raw)
In-Reply-To: <m1aer9je4i.fsf@alogconduit1ae.ccr.net>
Hi,
On 30 Aug 1999 13:51:41 -0500, ebiederm+eric@ccr.net (Eric W. Biederman)
said:
> A) Assuming we are doing intensive drawing whatever we are doing with
> the accellerator needs to happen about 30 times per second. That
> begins the aproximate limit on humans seeing updates.
> B) At 30hz we can do some slightly expensive things.
> To a comuputer there is all kinds of time in there.
Sure, *if* you can get away with activating the accel queue just once
per cycle. Who gets woken up when accel is done, btw? How do we
restore fb access?
> C) We could simply put all processes that have the frame buffer
> mapped to sleep during the interval that the accel enginge runs.
Ouch. Think about games --- performance is the most important thing for
them, and they want all the CPU they can get. They most certainly do
NOT want to be stalled just because the framebuffer is out of bounds:
there may be other useful things they could be calculating in the mean
time.
> D) We could keep a copy of the frame buffer (possibly in other video
> memory) and copy the ``frame buffer'' over, (with memcpy in the kernel, or with an
> accel command).
> At 1600x1280x32 x30hz that is about 220 MB/s. Is that a figure achieveable in the
> real world?
Not even close. At least, not without consuming 100% cpu and bus bandwidth.
> E) Nowhere does it make sense to simultaneously access the accelerator
> and frame buffer simultaneously. ( At least the same regions of the frame buffer).
> Because the end result on the screen would be unpredicatable.
> Therefore it whatever we use for locks ought to be reasonable.
That's a user space issue. If you have full framebuffer access and you
mess up the screen, it's your fault, no big deal. If you crash the
machine, that's an entirely different matter.
--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 20:36 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
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 [this message]
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.60217.253262.910401@dukat.scot.redhat.com \
--to=sct@redhat.com \
--cc=ebiederm+eric@ccr.net \
--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