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

Daryll Strauss (daryll@precisioninsight.com)
Sun, 19 Dec 1999 08:50:36 -0800


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