linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: James Simmons <jsimmons@edgeglobal.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Marcus Sundberg <erammsu@kieraypc01.p.y.ki.era.ericsson.se>,
	linux-mm@kvack.org
Subject: Re: accel handling
Date: Mon, 30 Aug 1999 10:50:11 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.9908301043070.3506-100000@imperial.edgeglobal.com> (raw)
In-Reply-To: <14282.37533.98879.414300@dukat.scot.redhat.com>

> The only way to do it is to flip page tables while the accel engine is
> running.  You may want to restore it on demand by trapping the page
> fault on the framebuffer and stalling until the accel lock is released.
> This can be done, but it is really expensive: you are doing a whole pile
> of messy VM operations every time you want to trigger the accel engine
> (any idea how often you want to flip the protection, btw?)
>

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.  
 
> So you are talking several system calls, SMP inter-processor interrupts
> and piles of VM page twiddling every time you want to claim and release
> the core engine.  Sorry, folks, but there's no way of avoiding the
> conclusion that this is going to be expensive.  In the single-CPU or
> single-thread case the cost can be kept under control, but it is not
> going to be cheap.

The secert is to do a as few times possible.

--
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/

  reply	other threads:[~1999-08-30 14:50 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 [this message]
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
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=Pine.LNX.4.10.9908301043070.3506-100000@imperial.edgeglobal.com \
    --to=jsimmons@edgeglobal.com \
    --cc=erammsu@kieraypc01.p.y.ki.era.ericsson.se \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    /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