Messages in this thread | | | Date | Tue, 14 Dec 1999 23:02:57 -0500 (EST) | From | James Simmons <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
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/
| |