Messages in this thread | | | Date | Sun, 19 Dec 1999 08:50:36 -0800 | From | Daryll Strauss <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
> Use DRI if you never will program the video card yourself and your > machine will never be on line so someone can break in and damage your > hardware. > Don't use DRI or be warned that using it can be dangerous if you are > online and someone can break in and damage your system or if you want to > write your own graphics software. The choice should be up to the public.
First of all, there is no way to damage the hardware while using the DRI. Pure and simple.
Second of all, a page mapping solution will not work with many existing pieces of hardware. On current boards you must do multiple writes to complete an operation, therefore the granularity of locking provided by page mapping is wrong.
Third of all, the DRI solution can be used to provide access to arbitrary sets of pages. If there are pages that processes shouldn't be able to use then the DRI can be used to exclude those pages. Your page mapping system gives exactly the same level of access to the hardware as the DRI.
Fourth of all, there is no such thing as a setuid library, and none of the code in the DRI is setuid. I have no idea what you meant by that comment.
Fifth of all, the DRI can be used for a page mapping solution if that is actually better for your hardware. There's nothing preventing that. In that aspect, our solution is actually a superset of yours.
There is one disadvantage of any direct rendering solution with current hardware. We can't prevent an application from scribbling over the entire screen instead of staying contained to their own window. Any solution that gives applications direct access to the hardware will have this problem unless the hardware has some way of limiting drawing arbitrarily complex sets of pixels. (For those who know graphics hardware, hardware with GID planes may be able to do this) Your page mapping system, if it worked on current hardware, would have the exact same limitations.
Another possible solution to the problem of scribbling is to not provide direct access to the hardware, and instead have the graphics interface in the kernel. This is an unacceptible answer because it would bloat the kernel and would have horrible performance. So direct access (of one form or another) really is the only reasonable solution.
> Their has been talk about porting a Direct X clone to linux. So as you > see their are other things besides OpenGL that will need to use the > graphics engine.
And, there would be NOTHING stopping them from writing a DirectX clone, except for Microsoft's lawyers, on top of the DRI. We expect the DRI to be used for other applications that can take advantage of more direct access to the graphics hardware. If someone wants to make a postscript DRI library, an X11 DRI library, or anything else, there is nothing stopping them.
Today we don't support using the DRI without an X server running. We think running under X is the right solution so that's what we implemented, but there's no reason someone else can't change that if they desire. There are a few services that the X server provides for the DRI. If those services were moved out of the server, then you could do DRI style rendering directly on the console. There's nothing preventing that. We just didn't write the code.
- |Daryll
- 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/
| |