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

James Simmons (jsimmons@edgeglobal.com)
Tue, 14 Dec 1999 13:19:39 -0500 (EST)


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