Re: Thread-private mappings and graphics (was Re: Per-Processor Data

James Simmons (jsimmons@edgeglobal.com)
Tue, 14 Dec 1999 23:02:57 -0500 (EST)


Thanks for the code. I will implement this.

James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net

On Tue, 14 Dec 1999, David S. Miller wrote:

> Date: Tue, 14 Dec 1999 09:42:00 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
>
> > The reason
> > DRE (Direct Rendering Engine) needs this is to ensure a page
> > fault happens.
>
> No. Add a pointer to the mapping in the graphics context, and you
> can do the same thing. Each graphics context gets associated with
> the particular mapping you have.
>
> This is precisely one of the other suggestions I was going to make.
>
> It's pretty straight forward:
>
> dre_nopage(vma, address) {
> struct dre_kernel_state *p;
>
> p = dre_lookup(vma->vm_mm, address);
> if (p->card->owner != p) {
> lock(p->card);
> remove_mappings(p->card->owner);
> idle_graphics_engine(p->card);
> save_card_state(p->card->owner);
> reload_card_state(p);
> p->card->owner = p;
> unlock(p->card);
> }
> fill_in_page_table(p->card, vma, address);
> }
>
> And then you provide an ioctl or whatever interface so that
> the graphics library can tell you which addresses to associate
> with which rendering state instance (for the dre owners, and
> the lookup function). It's pretty complex isn't it? :-)
>
> And it's amazing, no other part of the kernel even knows
> about what you're doing. :-)
>
> 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/
>

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