lkml.org 
[lkml]   [1999]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data Page)
   Date: Thu, 16 Dec 1999 17:31:37 -0500
From: Raul Miller <moth@magenta.com>

If you're swapping a lot, that would seem to have all the cost of
not putting all the registers in the card, while if you're not
swapping often it doesn't seem like there's a whole lot of
advantage to one methodology over another.

In one instance I know of a card that caches multiple rendering
context's state, something like up to 8, in the card. So the
kernel page fault handler would go:

change_dre_owner()
{
if (new_owner->in_hw)
writeb(new_owner->cookie, card->ctx_reg);
else
expensive_full_card_save_restore();
}

And it's as if you'd saved/restored the entire card state
when you write that magic context number into the cards register.

The core point is that the user process just uses the hardware
as if he had it the whole time, foregoing the locking necessary
by many current generate cards.

It's sort of like UNIX task swithing, the user process runs as if
he had the whole cpu to himself all the time, when really he doesn't
and the cpu is shared across multiple executing tasks.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.127 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site