Messages in this thread | | | Date | Tue, 14 Dec 1999 13:19:39 -0500 (EST) | From | James Simmons <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
[snip]
> In short, you didn't care about the BEAUTY.
You are right about the idea of not breaking a concept. Its true I shouldn't break a standard concept to do what a single driver/project wants done. If this was the case their would be no standards. Egg on my face :(
> > 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 the idea I will work on. The main point of the last email to point out what I was trying to do. Ensure a page fault for each access to accel engine whether it be by a thread or a forked process. Also avoid having to do a massive rewrite of threaded OpenGL. If their is another way besides private mapping that acceptable by everyone and gives just as good or better performace then I will use that method.
> Or do graphics contexts by hand, without depending on page faults. > Have a lock. > > I'm not asking you. I'm TELLING you that your idea will not be accepted > in the standard kernel. I can go on explaining all day WHY, but you > don't seem to care.
No. I'm willing to listen to suggestion by you and the other parties have here. Otherwise I wouldn't have posted to this mailing list. When it comes to ideas how often does someone else come up with a even better idea. I see your point about keeping standards and I will stick by them.
James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
- 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/
| |